RFC Errata
Found 2 records.
Status: Held for Document Update (2)
RFC 4240, "Basic Network Media Services with SIP", December 2005
Source of RFC: IETF - NON WORKING GROUPArea Assignment: rai
Errata ID: 839
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-23
Held for Document Update by: Robert Sparks
(2) [ minor textual improvement ]
In the final paragraph of section 3.3, on mid-page 11, perhaps
the words "most anything" should be replaced by "almost anything".
(3) [ textual improvement ]
The last paragraph on page 12 (within Section 4.1.) apparently
contains a plural/singular inconsistency.
The text says:
vvv vvv
The media server presents the parameters as environment variables in
the connection object. Specifically, the parameter appears in the
connection.sip tree. ^^^ ^^^
It should better say:
The media server presents the parameters as environment variables in
| the connection object. Specifically, the parameters appear in the
connection.sip tree.
(4) [ inconsistent terminology ]
I suspect that section 5 contains an unintentional inconsistency
in the terminology used:
The syntax element represented by the 'uniqueIdentifier' part
of the example in the 9th line of Section 5 apparently is
referred to as the "conf-id value" in various places (once
on page 13, 11th text line from the bottom of the page, and
4 occurrences on page 14 (text lines 3, 9, 12, and 13).
But in the 'Formal Syntax' Section 5.2., this syntactic
element is named "instance-id" (see bottom of page 16).
It certainly would be preferrable to always use the same
terminology; you should decide which term should be used.
(5) [ editorial artifact ]
The call flow diagram on page 15 unnecessarily 'overflows'
to page 16. The two first text lines on page 16,
| | | | |
| | | | |
do not carry any useful information and might better have been
suppressed.
(6) [ mismatch between diagram and explanation ]
Subsequently, near the top of page 16, the explanation of the
call flow diagram on page 15 says:
Note that the above call flow does not show any 100 TRYING messages
that would typically flow from the Application Server to the UACs;
nor does it show the ACKs from the UACs to the Application Server or
from the Application Server to the Media Server.
The latter is not true; the diagram in fact DOES show these ACKs !
Therefore, this paragraph should be shortened to just say:
Note that the above call flow does not show any 100 TRYING messages
that would typically flow from the Application Server to the UACs.
(7) [ confusion between concrete and abstract parameter names ]
In the 'IANA Considerations' Section 6., on page 17, the
registered lines mix concrete (real) parameter names (like
'play') with the meta-parameter name 'extension' in a way
that might mislead the reader to taking 'extension' as a
concrete parameter name as well.
>From Section 3.3., it can clearly be seen that this is merely
a placeholder for any additional parameter that might be
standardized in the future.
I'm seriously in doubt whether it is a good idea to register
this meta-parameter. Rather, future standards defining
concrete instances for the 'extension-param' should register
those concrete parameter names.
I therefore propose to delete the final line from the list,
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
. . .
. . .
. . .
| extension no RFC 4240
and from the actual IANA registration performed.
(8) [ legacy left in text? ]
The 3rd paragraph of Section 7, on page 17, says:
This document explicitly addresses this issue. The user names
described in the text (namely annc, ivr, dialog, and conf) are
available for whatever local use a given SIP user agent or proxy
wishes for them. [ ... ]
The user name, 'ivr', does not appear in the remainder of the text.
Admittedly omitting any detailed research, I suspect its occurrence
to be an improper left-over from earlier drafts.
Thus, this text should say:
This document explicitly addresses this issue. The user names
| described in the text (namely annc, dialog, and conf) are
available for whatever local use a given SIP user agent or proxy
wishes for them. [ ... ]
It should say:
[see above]
Notes:
from pending
Errata ID: 154
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-23
Held for Document Update by: Robert Sparks
Section 3.3 says:
A number of MIME registrations, which could be used here, have
parameters, for instance, video/DV. To accommodate this, and retain
compatibility with the SIP URI structure, the MIME-type parameter
separator (semicolon, %3b) and value separator (equal, %d3) MUST be
escaped. For example: ^^^
sip:annc@ms.example.net; \
play=file://fs.example.net//clips/my-intro.dvi; \
content-type=video/mpeg%3bencode%d3314M-25/625-50
It should say:
A number of MIME registrations, which could be used here, have
parameters, for instance, video/DV. To accommodate this, and retain
compatibility with the SIP URI structure, the MIME-type parameter
separator (semicolon, %3b) and value separator (equal, %3d) MUST be
escaped. For example:
sip:annc@ms.example.net; \
play=file://fs.example.net//clips/my-intro.dvi; \
content-type=video/mpeg%3bencode%3d314M-25/625-50