RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 4235, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", November 2005

Source of RFC: sipping (rai)

Errata ID: 2268
Status: Rejected
Type: Technical

Reported By: David Grant
Date Reported: 2010-05-18
Rejected by: Robert Sparks
Date Rejected: 2010-10-07

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.
--VERIFIER NOTES--
(From reviewer Dale Worley):

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:alice@example.com</identity>
<target uri="sip:alice@pc33.example.com">
<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:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/>
</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>.)

Report New Errata