Subject: [siprec] Consensus calls from session 2

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Sep 2011 17:59:58 +0200

Please raise any objections by 2011-10-03 to the following conclusions from today's call:

- List of SSRCs to be part of the association between participant and session.
- Extension data representation in XML as proposed on metadata slide 19.
- Structured <nameId/> element for use within a <participant/> element as shown on slide 20 (subject to clarification on need for language attribute).
- Adoption of XML syntax from RFC 4235 for representation of capabilities in metadata.

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 24 Sep 2011 03:10:55 +0000

> - Extension data representation in XML as proposed on metadata slide 19.

I don't understand what slide 19 means (ie, what it's changing), but I will re-iterate again that the extensionData container element is completely unnecessary, and potentially dangerous. 

It's unnecessary because XML doesn't need this type of thing.  All you need to do is have the RFC say "Unknown elements at any level MUST be ignored, and MUST NOT cause protocol failure".  That's what we do in other SIP RFCs. Why?  Because that's what xmlns namespaces are for.  You can extend it with vendor-proprietary and future-standard extensions at any time in the future, without backwards compatibility problems.  This is not some new concept for XML.

It's dangerous because we can only extend the XML document in future specs in the places where we happened to put the extensionData element.  And what happens if/when we do extend this XML in a future spec by putting a newly defined XML container element inside extensionData?  Do we have to put another extensionData inside that new container too, just in case we want to extend it again in the future?

What would a future spec do about vendor-proprietary elements which happen to be sharing the same extensionData container defined by this metadata document?  The future spec would say: "you have to implement XML, which has namespaces, and ignore any elements not using this new spec's namespace or one you understand".  Well gee, that's what we can do right now without using an extensionData container to begin with.

-hadriel
p.s. sorry for the rant. :(

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 26 Sep 2011 11:11:15 +0530

Hadriel,

I'm not convinced with you proposal because I noticed the standard way
to
represent the extension (standard or proprietary) in XML using xs:any
and 
it is incorporated in RFC 6120 (latest XMPP core RFC) and IMO, it is
more 
like generic-param in ABNF notation but allows other schema within.
Also,
http://www.ietf.org/mail-archive/web/siprec/current/msg02718.html mail 
thread discussion details with whether the extensiondata has to be 
mentioned within XML sequence of not. 

Including Peter (Tech advisor for SIPREC XML and author of RFC 6120) to 
Provide his comments for the closure in this open item.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Hadriel Kaplan
>Sent: Saturday, September 24, 2011 8:41 AM
>To: Elwell, John
>Cc: [email-masked]
>Subject: Re: [siprec] Consensus calls from session 2
>
>
>> Please raise any objections by 2011-10-03 to the following
conclusions
>from today's call:
>I don't understand what slide 19 means (ie, what it's changing), but I
>will re-iterate again that the extensionData container element is
>completely unnecessary, and potentially dangerous.
>
>It's unnecessary because XML doesn't need this type of thing.  All you
>need to do is have the RFC say "Unknown elements at any level MUST be
>ignored, and MUST NOT cause protocol failure".  That's what we do in
>other SIP RFCs. Why?  Because that's what xmlns namespaces are for.
You
>can extend it with vendor-proprietary and future-standard extensions at
>any time in the future, without backwards compatibility problems.  This
>is not some new concept for XML.
>
>It's dangerous because we can only extend the XML document in future
>specs in the places where we happened to put the extensionData element.
>And what happens if/when we do extend this XML in a future spec by
>putting a newly defined XML container element inside extensionData?  Do
>we have to put another extensionData inside that new container too,
just
>in case we want to extend it again in the future?
>
>What would a future spec do about vendor-proprietary elements which
>happen to be sharing the same extensionData container defined by this
>metadata document?  The future spec would say: "you have to implement
>XML, which has namespaces, and ignore any elements not using this new
>spec's namespace or one you understand".  Well gee, that's what we can
>do right now without using an extensionData container to begin with.
>
>-hadriel
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 26 Sep 2011 09:10:56 +0200

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 24 September 2011 04:11
> To: Elwell, John
> Cc: [email-masked]
> conclusions from today's call:
[JRE] What slide 19 does is get rid of an unnecessary level of <sequence/>. In metadata-04 the schema defines an element type extensiondata and uses it in various places. This type is defined as being a complexType consisting of the "xs:any" construct. This is not valid syntax, and to make it valid xs:any would need to be embedded within a <sequence/> element, e.g.:
     <xs:element name='extensiondata'>
        <xs:complexType>
          <sequence>
            <xs:any     namespace='##other'
                        minOccurs='0'
                        maxOccurs='unbounded'
                        processContents='lax'/>
          </sequence>
        </xs:complexType>
This can be avoided simply by putting the xs:any construct within any sequence where extension data is needed, such as within the session, group, participant and stream sequences. Defining a separate type extensiondata seems to force an additional level of sequence on the wire.

So this change is merely about making our schema valid and doing so without forcing an unnecessary level of sequence on the wire. We can have a separate discussion on whether the xs:any construct is needed at all, but that is not what this consensus call is about.

> 
> I don't understand what slide 19 means (ie, what it's 
> changing), but I will re-iterate again that the extensionData 
> container element is completely unnecessary, and potentially 
> dangerous. 
> 
> It's unnecessary because XML doesn't need this type of thing. 
>  All you need to do is have the RFC say "Unknown elements at 
> any level MUST be ignored, and MUST NOT cause protocol 
> failure".  That's what we do in other SIP RFCs. Why?  Because 
> that's what xmlns namespaces are for.  You can extend it with 
> vendor-proprietary and future-standard extensions at any time 
> in the future, without backwards compatibility problems.  
> This is not some new concept for XML.
> 
> It's dangerous because we can only extend the XML document in 
> future specs in the places where we happened to put the 
> extensionData element.  And what happens if/when we do extend 
> this XML in a future spec by putting a newly defined XML 
> container element inside extensionData?  Do we have to put 
> another extensionData inside that new container too, just in 
> case we want to extend it again in the future?
[JRE] No, I don't think so. That is why the maximum number of instances of xs:any is unbounded.

John

> 
> What would a future spec do about vendor-proprietary elements 
> which happen to be sharing the same extensionData container 
> defined by this metadata document?  The future spec would 
> say: "you have to implement XML, which has namespaces, and 
> ignore any elements not using this new spec's namespace or 
> one you understand".  Well gee, that's what we can do right 
> now without using an extensionData container to begin with.
> 
> -hadriel

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 26 Sep 2011 20:09:50 +0530

Hadriel,

As John mentioned below, the consensus call was for avoiding the
unnecessary level of sequence as defined in ver 04 and go with simple
approach of putting the xs:any construct within any sequence where
extension data is needed [ e.g. session, group, participant and stream
sequences]. Also we agreed in the call(Monday session) that extension
data is not needed to be modeled in UML. Please note this schema is
inline with technique used in RFC 6120 (XMPP related RFC) for extension
data.

The schema for <session/>, for example, with the above approach will be:

      <xs:complexType name="session">
          <xs:sequence>
            <xs:element name="associate-time" type="dateTime"
                   minOccurs="0"/>
            <xs:element name="disassociate-time" type="dateTime"
                   minOccurs="0"/>
            <xs:element name="reason" type="xs:string"
                   minOccurs="0"/>
            <xs:element name="group-ref" type="urnuuid"
                   minOccurs="0" maxOccurs="1"/>
            <xs:any namespace='##other'
                   minOccurs='0'
                   maxOccurs='unbounded'
                   processContents='lax'/>
          </xs:sequence>
          <xs:attribute name="id" type="urnuuid"
               use="required"/>
      </xs:complexType>

Let me know if you still have any concerns.

Regards,
Ram

> Behalf Of Elwell, John
> Sent: Monday, September 26, 2011 12:41 PM
> To: Hadriel Kaplan
> Cc: [email-masked]
> [JRE] What slide 19 does is get rid of an unnecessary level of
> <sequence/>. In metadata-04 the schema defines an element type
> extensiondata and uses it in various places. This type is defined as
> being a complexType consisting of the "xs:any" construct. This is not
> valid syntax, and to make it valid xs:any would need to be embedded
> within a <sequence/> element, e.g.:
> This can be avoided simply by putting the xs:any construct within any
> sequence where extension data is needed, such as within the session,
> group, participant and stream sequences. Defining a separate type
> extensiondata seems to force an additional level of sequence on the
> wire.
> 
> So this change is merely about making our schema valid and doing so
> without forcing an unnecessary level of sequence on the wire. We can
> have a separate discussion on whether the xs:any construct is needed
at
> all, but that is not what this consensus call is about.
> 
> >
> [JRE] No, I don't think so. That is why the maximum number of
instances
> of xs:any is unbounded.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Sep 2011 09:27:10 -0600

First, I'm sorry that I have very limited cycles to engage in this
working group.

I see this as a stylistic matter in scheme definition. Yes, Hadriel is
right that in theory XML lets you extend anywhere. In practice,
developers and deployers often like to know what the extension points
are. For example, some organizations that deploy XMPP in high-security
environments perform real-time schema checking to ensure that
potentially harmful data is not sent between servers or from clients.
However, as I said I think this is a stylistic matter -- one could even
define a strict schema and a more relaxed schema.

Unlike Hadriel, I see no harm in defining the Extensiondata element as
the primary location for future extension work. On the other hand, I
don't think there is value in programmatically limiting extension work
to the Extensiondata element and I think it would be harmful to say that
an application must return an error if extensions are included (via XML
namespaces) in places other than the Extensiondata element.

Peter

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 26 Sep 2011 22:55:10 +0530

Hi Peter,

Thanks for your inputs. I was not aware of the fact that xs:any 
is just stylistic manner in schema definition. 

Hi all,

As per Peter below inputs, SIPREC metadata shall define xs:any
in the each metadata element without any sequence for the general 
guidelines of extensiondata within metadata element. For example 
(John proposed in another mail thread):

There is no error defined for this extension. 

Please let me know in case anybody have disagreement with this
approach.

Thanks
Partha

>From: Peter Saint-Andre [mailto:[email-masked]]
>Sent: Monday, September 26, 2011 8:57 PM
>To: Ravindran Parthasarathi
>Cc: Hadriel Kaplan; Elwell, John; [email-masked]
>Subject: Re: Extensiondata in SIPREC metadata same as XMPP xs:any
>mechanism [was RE: [siprec] Consensus calls from session 2]
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Sep 2011 21:01:06 +0000

> This can be avoided simply by putting the xs:any construct within any sequence where extension data is needed, such as within the session, group, participant and stream sequences. Defining a separa…

Ahhh - so what you're saying (I think) is that you *ARE* getting rid of the "extensiondata" elements, and just using the xs:any schema extension construct as per normal XML.  Right?

Sorry, that wasn't clear to me from the slides.
Good, so ignore my rant.  Nothing to see here… move along. :)

Oh, except I suggest the metadata document have this sentence in it somewhere:
   Other elements from different namespaces MAY be
   present for the purposes of extensibility; elements or attributes
   from unknown namespaces MUST be ignored.

I didn't see that type of statement in it, but we should probably have it.

-hadriel