RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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 GROUP
Area 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

Report New Errata



Advanced Search