Subject: RFC 4240

From: Alfred Hönes <[email-masked]>
Date: Mon, 23 Jan 2006 17:17:01 +0100 (MEZ)

Hello,
reading the recently published RFC 4240 authored/edited by you
I found a couple of textual flaws -- ranging from simple typos
to more substantial issues.

I'll present these in (approximate) RFC text order, deliberately
using change bars, '|', in the first column and/or '^^^' / 'vvv'
style (up/down pointing) tags to point to offending locations
within the excerpts from the original text, and/or the proposed
modified text.

(1)  [ significant "character twister" ]

In Section 3.3., the text and example near the bottom of page 10
contain wrong escape sequences.  The correct ecsape sequence for
the value separator (equals sign) is %3d (or: %3D), not %d3 !
Therefore, the paragraphs,

   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:[email-masked]; \
       play=file://fs.example.net//clips/my-intro.dvi; \
|      content-type=video/mpeg%3bencode%d3314M-25/625-50
                                       ^^^
should correctly 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:[email-masked]; \
       play=file://fs.example.net//clips/my-intro.dvi; \
|      content-type=video/mpeg%3bencode%3d314M-25/625-50

(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.  [ ... ]

Please comment.
Some of these issues require your decision or action to be
resolved.  IMHO, most items should be considered for inclusion
in an RFC Errata Note.  Please make use of the material presented
above to directly submit an Author Errata Note or give me your
direction (and consent) to formally submit an Errata Note on my own.

Best Regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+