RFC Errata
Found 23 records.
Status: Verified (15)
RFC 5022, "Media Server Control Markup Language (MSCML) and Protocol", September 2007
Source of RFC: INDEPENDENT
Errata ID: 1239
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 6.1.1.1 says:
Attributes of <audio>:
o url - required, no default value: The URL of the content to be
retrieved and played. The target may be a local or remote (NFS)
"file://" scheme URL or an "http://" or "https://" scheme URL. If
the URL is not fully qualified and a "baseurl" attribute was set,
the value of the "baseurl" attribute will be prepended to this
value to generate the target URL.
It should say:
< see Notes >
Notes:
Again, the RFC should make use of standard terminology
established in the IETF.
STD 66, RFC 3986 should be used here.
The attribute, 'url', should better have been named 'uri'.
Consequently, all subsequent references to an URL w.r.t. this
attribute should be replaced by "URI" or "URI reference", as
appropriate.
Authors comment: This is really an Editorial erratum. If it were to be changed, it should be changed consistently throughout the document.
Errata ID: 1242
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 6.1.1.1. says:
o rate - optional, default value "0": Specifies the absolute
playback rate of the content relative to normal as either a
positive percentage (faster) or a negative percentage (slower).
Any value that attempts to set the rate above the maximum allowed
or below the minimum allowed silently sets the rate to the maximum
or minimum. The rate reverts back to its original value when
playback of the content URL has been completed.
It should say:
| o rate - optional, default value "0": Specifies the deviation of the
| content playback rate from its normal value as either a positive
percentage (faster) or a negative percentage (slower).
Any value that attempts to set the rate above the maximum allowed
or below the minimum allowed silently sets the rate to the maximum
or minimum. The rate reverts back to its original value when
| playback of the content specified by the URI has been completed.
Notes:
There is perfect confusion between 'absolute' and 'relative",
leaving this specification open to gross misunderstanding.
I hope the proposed replacement text says what had been intended
to say; it also corrects sluggish language and applies STD 66 terms.
Errata ID: 1247
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 6.5.3, p.41 says:
The recording example (Figure 19) plays a prompt and records it to the destination specified in the "recurl" attribute encoded as MS-GSM in wave format.
It should say:
| The recording example (Figure 19) plays a prompt and records the | response to the destination specified in the "recurl" attribute encoded as MS-GSM in wave format.
Notes:
The RFC text is ambiguous/misleading; what does 'it' refer to ?
I guess that nobody will be interested in recording the prompt.
Therefore, I hope the clarification above says what has been intended.
Errata ID: 1248
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 8, page 48 says:
Managecontent Attributes:
o src - required, no default value: Specifies the local source URL
of the content. The URL scheme MUST be "file://".
o dest - required (see note), no default value: Specifies the
destination URL. The URL scheme MUST be "http://". Note: If the
selected action is 'delete', this attribute is optional; otherwise
it is required.
It should say:
Managecontent Attributes:
| o src - required, no default value: Specifies the local source URI
| of the content. The URI scheme MUST be "file".
o dest - required (see note), no default value: Specifies the
| destination URI. The URI scheme MUST be "http". Note: If the
selected action is 'delete', this attribute is optional; otherwise
it is required.
Notes:
a)
The RFC should follow STD 66, RFC 3986 terminology and syntax.
URI schemes do not allow ':' and '/' -- see Section 3.1 (p.17) of RFC 3986.
b) ... MUST be "http" ...
Why the hack does the RFC explicitely forbid using HTTP security
and the "https" URI scheme ????
(I do not believe the authors expect the use of "Upgrade to TLS"
within HTTP, which is rarely implemented -- although it once was
intended as a generice security layer drop-in mechanism.)
Authors comment: Yes, HTTP is a MUST implement, though not the only option here.
Errata ID: 1234
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 5.5 says:
A client can modify a leg by issuing an INFO on the dialog associated | with the participant leg. For example, Figure 8 mutes a conference leg.
It should say:
A client can modify a leg by issuing an INFO on the dialog associated | with the participant leg. For example, the request in Figure 8 mutes a conference leg.
Notes:
Text below Figure 7 (on page 15) is misleading.
Figure 8 is printed on the paper sheet in my hand
and does not mute anything :-)
Errata ID: 1235
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 5.7, 3rd par says:
| A request for an active talker report is in Figure 9. The active talker report enumerates the current call legs in the mix.
It should say:
| A request for an active talker report is shown in Figure 9. The active talker report enumerates the current call legs in the mix.
Notes:
Improved language.
Errata ID: 1236
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 5.8.2.3 says:
The corresponding MSCML request is as follows. <?xml version="1.0"?> <MediaServerControl version="1.0"> ... Figure 12: Join Agent Request
It should say:
The corresponding MSCML request is as follows. | <?xml version="1.0"?> <MediaServerControl version="1.0"> ... Figure 12: Join Agent Request
Notes:
On page 22, the XML shown in Figure 12 should have been separated
from the preceding text with a blank line.
The same issue recurs in Section 5.8.2.4 below (on the same page),
with respect to Figure 13.
Errata ID: 1240
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 6.1.1.1. says:
o gain - optional, default value "0": Sets the absolute gain to be
applied to the content URL. [...]
It should say:
o gain - optional, default value "0": Sets the absolute gain to be
applied to the content specified by the URI. [...]
Notes:
Sluggish language --
can't mute an URI, or apply gain to an URI ! :-)
Note that other errata request the change from URL to URI throughout.
Errata ID: 1241
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 6.1.1.1 says:
o gaindelta - optional, default value "0": Sets the relative gain to
| be applied to the content URL. The value of this attribute is
specified in units of dB. The media server MAY silently cap
values that exceed the gain limits imposed by the platform. The
level reverts back to its original value when playback of the
| content URL has been completed.
It should say:
o gaindelta - optional, default value "0": Sets the relative gain to
| be applied to the content specified by the URI. The value of this
attribute is specified in units of dB. The media server MAY
silently cap values that exceed the gain limits imposed by the
platform. The level reverts back to its original value when
| playback of the content has been completed.
Notes:
Again, sluggish language (and non-use of STD 66 terminology).
Errata ID: 1243
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 6.1.1.1 p.29 says:
Spoken variables are specified using the <variable> element. This element has the attributes described in the list below. MSCML's | spoken variables are based on those described in Audio Server Protocol [17].
It should say:
Spoken variables are specified using the <variable> element. This element has the attributes described in the list below. MSCML's | spoken variables are based on those described in the Audio Server Protocol [17].
Notes:
Missing article (mid-page 29).
Author comment: Good catch.
Errata ID: 1245
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 6.4.3 says:
a)
... "immediate" and "infinite." (3 instances)
b)
... returnkey is set to #, ...
It should say:
a)
... "immediate" and "infinite". (3 instances)
b)
... returnkey is set to "#", ...
Notes:
a) Syntax error; apply 'rational quotation' !
The issue occurs in the 1st, 3rd, and 4th bullet on page 35.
b) Clarification; the single pound character needs to be double-quoted
in the XML anyway, isn't it?
This also will make the text more uniform.
Errata ID: 1246
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 6.5.2, p.40 says:
."
It should say:
".
Notes:
Again, in the second to seventh bullet on page 40,
'rational quotation' should be applied (6 instances).
Errata ID: 1249
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 8, page 49 says:
o name - required (see note), no default value: Specifies the field
name for the content in the form when using the 'post' method.
This is not to be confused with the "src" or "dest" attributes.
| Note: This attribute is required when the "htttpmethod" has the
value "post" and is optional otherwise.
It should say:
o name - required (see note), no default value: Specifies the field
name for the content in the form when using the 'post' method.
This is not to be confused with the "src" or "dest" attributes.
| Note: This attribute is required when the "httpmethod" attribute
has the value "post" and is optional otherwise.
Notes:
A typo, and sluggishly inprecise use of language.
Errata ID: 1251
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 8.1, last pa says:
." (2 instances)
It should say:
".
Notes:
The last paragraph of Section 8.1 again contains two syntax errors
based non non-pplication of 'rational quoting'.
Errata ID: 1254
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28
Section 9.2, Table 5 says:
... it MUST match remote terminal's identifier ...
It should say:
... it MUST match the remote terminal's identifier ...
Notes:
Insert the missing article in the 5th line from the bottom of Figure 5.
Status: Rejected (8)
RFC 5022, "Media Server Control Markup Language (MSCML) and Protocol", September 2007
Source of RFC: INDEPENDENT
Errata ID: 1233
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28
Section 5.2 says:
Attributes of <configure_conference>:
o reservedtalkers - optional (see note), no default value: The
maximum number of talker legs allocated for the conference. Note:
+ required when establishing the Conference Control Leg but optional
+ in subsequent <configure_conference> requests.
o reserveconfmedia - optional, default value "yes": Controls
allocation of resources to enable playing or recording to or from
? the entire conference.
?
? When the reservedtalkers+1st INVITE arrives at the media server, the
media server SHOULD generate a 486 Busy Here response. Failure to
send a 486 response to this condition can cause the media server to
oversubscribe its resources.
It should say:
< amended/clarified text should be supplied by authors >
Notes:
The text spanning from page 12 to page 13 lacks of precision.
In the first bullet, it precisely specifies in which kind of leg
the attribute applies.
Similar information is missing entirely from the second bullet.
Also, it is not unambiguously clear whether "reservedtalkers+1st INVITE"
shall count the control leg or not.
Without added clarification, interoperability might suffer.
Authors response: In four years of deployment, no one has run into a real problem in the real world. No change needed.
--VERIFIER NOTES--
Errata ID: 1237
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28
Section 6.1.1 says:
URL and URLs
It should say:
URI and URIs
Notes:
Throughout Section 6.1.1. ff., the RFC should better use
IETF standard terminology as codified in STD 66, RFC 3986.
In particular, the attribute name "baseurl" is a misnomer
and should better have been named "baseuri" (bottom of page 24).
--VERIFIER NOTES--
Author comment: Sounds editorial to me. If you want to change it everywhere, go for it. Changing baseurl to baseuri would change the protocol. Since it really is a seven-character string that seems to mean something, no harm in leaving it as is.
Errata ID: 1238
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28
Section 6.1.1 says:
o locale - optional, no default value: Specifies the language and
country variant used for resolving spoken variables. The language
is defined as a two-letter code per ISO 639. The country variant
is also defined as a two-letter code per ISO 3166. These codes
are concatenated with a single underscore (%x5F) character.
It should say:
< to be specified >
Notes:
The RFC should better apply existing IETF standards and not
try to establish ad-hoc usage conventions and/or syntaxes
for details already well specified in the IETF.
In particular, it is considered an error (on top of page 26)
to not apply, and refer to, RFC 4646 (BCP 47) for the
definition of language tags.
RFC 4646 deliberately has modified and extended the earlier
conventions roughly corresponding to what is described here.
--VERIFIER NOTES--
Authors comment: BCP 47 wasn't out yet when the base spec was published.
A new protocol - hence a new RFC - should make the changes suggested here.
Errata ID: 1244
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28
Section 6.1.1.1 p.29 says:
Attributes of <variable>:
o type - required, no default value: Specifies the major type format
of the spoken variable to be played. Allowable values are "dat"
(date), "dig" (digit), "dur" (duration), "mth" (month), "mny"
(money), "num" (number), "sil" (silence), "str" (string), "tme"
(time), and "wkd" (weekday).
o subtype - optional, no default value: Specifies the minor type
format of the spoken variable to be played. Allowable values
depend on the value of the corresponding "type" attribute.
Possible values are "mdy", "ymd", and "dmy" for dates, "t12" and
"t24" for times, "gen", "ndn", "crd", and "ord" for digits, and
"USD" for money.
It should say:
< see Notes >
Notes:
The RFC here underspecifies many important details necessary
to be specified precisely to ensure interoperability:
a) What is the intended range of values for "wkd" ?
I guess, it may be "0", ..., "6" .
Or is it "1", ..., "7" ??
(Textual values make no sense -- or at least would make
implementations overly complicated requiring an any-language
to any-languange translation facility -- because the value
needs to be played out in the intended language according
to effective preferences.)
b) What are "gen", "ndn", "crd", and "ord" ?
No details are given to explain these abbreviations, and
most RFC readers will not be accustomed either to them.
I guess that "ord" might mean 'ordinal', "crd" be
'cardinal', and perhaps "gen" for 'generic', but "ndn" ?
The semantics need to be specified carefully for interoperability!
c) Another instance of overly US-centric thinking is the single "USD"
for money. To ensure wide-spread applicability and maintainability
of the protocol, the RFC should better apply the standard method
of incorporating the applicable 'official' registry by *reference*,
which in this case is the list of monetary units and their
internationally agreed-upon / assigned three-character
abbreviations from the ISO 4217 Maintenance Agency.
--VERIFIER NOTES--
Authors comment: This is an Informational RFC, not a Standards Track one.
Errata ID: 1253
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28
Section 9.2 says:
Attributes of <faxplay>:
o lclid - optional, default value "" (the empty string): A string
that identifies the called station.
It should say:
Attributes of <faxplay>: o lclid - optional, default value "" (the empty string): A string | that identifies the calling station.
Notes:
I suspect that the RFC specifies the wrong station ID.
In Section 9.1, "lclid" clearly specifies the PSTN 'role'
the Media Server shall assume in processing a fax in answer mode;
there, it makes no sense to specify an identity that is not under
control of the media server accepting the incoming call.
Similarly, for <faxplay> in Section 9.2, the local ID the Media
Server shall assume in sending the fax needs to be specified;
as far as I understand the text, the Media Server is the *calling*
station in this scenario.
Should I be wrong with this diagnosis, perhaps other claraifcation(s)
to the RFC are needed.
--VERIFIER NOTES--
Authors comment: Incorrect diagnosis.
Errata ID: 1232
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28
Section 5.1, page 11 says:
When the conference is created by sending an INVITE containing a MSCML <configure_conference> payload, the resulting SIP dialog is | termed the "Conference Control Leg." This leg has several useful properties. The lifetime of the conference is the same as that of
It should say:
When the conference is created by sending an INVITE containing a MSCML <configure_conference> payload, the resulting SIP dialog is | termed the "Conference Control Leg". This leg has several useful properties. The lifetime of the conference is the same as that of
Notes:
Syntax error in second paragraph on page 11.
(Period is not part of the term.)
Please apply 'rational quotation' !
--VERIFIER NOTES--
This (period inside the quote marks) is a common typographic convention, especially among LaTeX users.
Errata ID: 1250
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28
Section 8, p.49-50 says:
MIME Type or: MIME type (multiple instances each)
It should say:
Media Type or: media type
Notes:
a)
The RFC should apply IETF standard terminology.
In this case, it is clear that the RFC does *not* apply to the
context of email, and hence "MIME" should be avoided even more!
Please use the terminology established in RFC 2045 ff. !
b)
Furthermore, Table 3 on page 50 contains a couple of questionable
entries:
audio/x-alaw-basic is a private media type;
audio/ms-gsm looks like an IETF tree media subtype,
but it has not been registered with the IANA;
audio/x-wav is also a private media type; I guess it should
better be audio/vnd.wave (RFC 2361)
-- although the IANA apparently has lost
records of this media type registration.
--VERIFIER NOTES--
Authors comment: In four years of deployment, no one has run into a real problem in the real world. This is not a standards track RFC.
Errata ID: 1252
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28
Section 9.1 says:
a)
URL
b)
://
c)
... it MUST match remote terminal's identifier, ...
It should say:
a)
URI
b)
(nothing!)
c)
... it MUST match the remote terminal's identifier, ...
Notes:
Again, this section should apply strict IETF established terminology,
as per STD 66, RFC 3986; it contains a wealth of badly formed said
[URI] schemes.
Throughout the section,
a) replace "URL" by "URI" , and
b) use the precise forms of the URI schemes mentioned,
i.e. "file" , "http" , "https" .
c) In Table 4 on page 52, insert the missing article in the
5th line from the bottom.
--VERIFIER NOTES--
Authors comment: In four years of deployment, no one has run into a real problem in the real world.