Subject: [sipcore] Errata report on errata 2268, 839, and 154

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 6 Oct 2010 14:24:37 -0400

This is a report on these RFC errata:

errata 2268 for RFC 4235
errata 839 for RFC 4240
errata 154 for RFC 4240

======================================================================
Errata ID: 2268
RFC4235, "An INVITE-Initiated Dialog Event Package for the Session
Initiation Protocol (SIP)"
Source of RFC: sipping (rai)

Status: Reported
Type: Technical

Reported By: David Grant
Date Reported: 2010-05-18

Section 4.2 says:

<xs:complexType name="sessd">
   <xs:simpleContent>
      <xs:extension base="xs:string">
         <xs:attribute name="type" type="xs:string" use="required"/>
      </xs:extension>
   </xs:simpleContent>
</xs:complexType>

It should say:

<xs:complexType name="sessd">
  <xs:attribute name="type" type="xs:string"/>
</xs:complexType>

Notes:

The sessd type is a simple type, which allows text content, yet the
RFC does not describe what content it should have, so it should be an
empty type instead.
----------------------------------------------------------------------
Recommended status:  Rejected

The description of the session-description element in section 4.1.6.3
is not particularly clear, but it is unambiguous:

   4.1.6.3.  Session Description Element

   The session-description element contains the session description used
   by the observed user for its end of the dialog.  This element should
   generally NOT be included in the notifications, unless it was
   explicitly requested by the subscriber.  It has a single attribute,
   "type", which indicates the MIME media type of the session
   description.  To avoid repeating session description information in
   each request, the subscriber can assume that the session description
   is the same as in previous notifications if no session description
   element is present in the corresponding local or remote element.

Therefore, a typical usage would be:

   <?xml version="1.0" encoding="UTF-8"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
     version="1" state="full">
     <dialog id="123456">
        <state>confirmed</state>
        <duration>274</duration>
        <local>
          <identity display="Alice">sip:[email-masked]</identity>
          <target uri="sip:[email-masked]">
            <param pname="isfocus" pval="true"/>
            <param pname="class" pval="personal"/>
          </target>
          <session-description type="application/sdp">v=0
o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com
s=Session SDP
t=0 0
c=IN IP4 pc33.atlanta.com
m=audio 3456 RTP/AVP 0 1 3 99
a=rtpmap:0 PCMU/8000
</session-description>
        </local>
        <remote>
          <identity display="Bob">sip:[email-masked]</identity>
          <target uri="sip:[email-masked]"/>
        </remote>
        <session-description type="application/sdp">[SDP sent by remote UA]</se\
ssion-description>
     </dialog>
   </dialog-info>

That is, <session-description> has a "type" attribute whose value is
the MIME type of the session description, and it has content which is
the session description.

(Note that both the <local> and <remote> elements have their own
<session-description>, as SDP is sent by both UAs.  Presumably the
<session-description> of a participant is the SDP that was *sent* by
that participant.)

Within this understanding, the XML schema language in the RFC is
correct.  The '<xs:extension base="xs:string">' specifies that the
content of <session-description> is a string, and the '<xs:attribute
name="type" type="xs:string" use="required"/>' specifies that
<session-description> must have an attribute 'type'.

(The situation could have been made much clearer if the RFC included
an example of the use of <session-description>.)
======================================================================
Errata ID: 839
RFC4240, "Basic Network Media Services with SIP"
Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Status: Reported
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-01-23

[Note that item (1) does not exist. -- DRW]

(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
----------------------------------------------------------------------
Recommended status:  Verified, hold for document update, except needs
correction of IANA registration.

(1) [Item (1) does not exist.]
(2) correct; hold for document update
(3) correct; hold for document update
(4) correct; hold for document update
(5) correct; hold for document update
(6) correct; hold for document update (However, it may be preferable
    to remote the ACKs from the diagram and not modify the text.)
(7) correct
    In addition, the "parameter name" param[n] is a meta-parameter name
    for the set param1, param2, param3, param4, param5, param6,
    param7, param8, and param9, as stated in section 3 of the RFC.

    In regard to the RFC, this item can be held for document update,
    but the IANA registry "SIP/SIPS URI Parameters" (in
    http://www.iana.org/assignments/sip-parameters) should be
    corrected by:

Remove:

    extension          No                    [RFC4240]
    param[n]           No                    [RFC4240]

Add:

    param1             No                    [RFC4240]
    param2             No                    [RFC4240]
    param3             No                    [RFC4240]
    param4             No                    [RFC4240]
    param5             No                    [RFC4240]
    param6             No                    [RFC4240]
    param7             No                    [RFC4240]
    param8             No                    [RFC4240]
    param9             No                    [RFC4240]

(8) correct; hold for document update
======================================================================
Errata ID: 154
RFC4240, "Basic Network Media Services with SIP"
Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-01-23

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:[email-masked]; \
       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
[ --------------------------------------------------------^^^
  -- DRW]

   escaped.  For example:

   sip:[email-masked]; \
       play=file://fs.example.net//clips/my-intro.dvi; \
       content-type=video/mpeg%3bencode%3d314M-25/625-50
[ Note this should be marked also:-----^^^
  -- DRW]
----------------------------------------------------------------------
Recommended status:  Verified, hold for document update

The erratum is correct, but the nature of the error will be obvious to
the serious reader.
======================================================================

Dale