Subject: Re: [siprec] Consensus calls from session 2

From: Paul Kyzivat <[email-masked]>
Date: Sun, 02 Oct 2011 13:23:42 -0400

On 9/26/11 10:39 AM, Ram Mohan R (rmohanr) wrote:
> 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.

I agree with this approach. I *don't* think it is good to expect 
recipients to ignore unknown elements in places where there is no "any" 
in the schema to match them. IOW, I think the message should be expected 
to validate according to the specified schema. It should be acceptable 
for a recipient to reject any message that doesn't. (But it should also 
be acceptable for a recipient to ignore unknown elements.)

I know that <xs:any namespace='##other' .../> is typically used to 
accomplish this. But I have wondered about the ##other in that 
construction. IIUC it means that you can't have anything from *this* 
namespace matching that. But that means that any extensions we might 
want to incorporate later would *require* a different namespace. While 
that is certainly possible, it might be inconvenient/annoying. Is there 
any reason to forbid things from this namespace being used?

	Thanks,
	Paul

> 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
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Elwell, John
>> Sent: Monday, September 26, 2011 12:41 PM
>> To: Hadriel Kaplan
>> Cc: [email-masked]
>> Subject: Re: [siprec] Consensus calls from session 2
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Hadriel Kaplan [mailto:[email-masked]]
>>> Sent: 24 September 2011 04:11
>>> To: Elwell, John
>>> Cc: [email-masked]
>>> Subject: Re: [siprec] Consensus calls from session 2
>>>
>>>
>>> On Sep 23, 2011, at 11:59 AM, Elwell, John wrote:
>>>
>>>> Please raise any objections by 2011-10-03 to the following
>>> conclusions from today's call:
>>>> - Extension data representation in XML as proposed on
>>> metadata slide 19.
>> [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
>>> p.s. sorry for the rant. :(
>>>
>>>
>> _______________________________________________
>> siprec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/siprec
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 3 Oct 2011 11:02:40 +0530

Hadriel,

In case your intention of the below proposal normative statement is to
avoid sending the error from SRS for the extension supported by SRC,
then the normative statement is not required because the extension may
be received in any place within namespace (not required in the specified
xs:any location) and it is the basics of XML and nothing do with
Metadata XML specifically.

Please correct me in case every new XML (namespace) document has to have
these extensions ignoring statement as per XML definition. 

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Hadriel Kaplan
>Sent: Saturday, October 01, 2011 2:31 AM
>To: Elwell, John
>Cc: [email-masked]
>On Sep 26, 2011, at 3:10 AM, Elwell, John wrote:
>
>within a <sequence/> element, e.g.:
>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
>
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 3 Oct 2011 18:37:51 +0200

I was also wondering why "<xs:any namespace='##other' .../>" is specified rather than "<xs:any namespace='##any' .../>".

Is there a good reason why we need to use "##other" rather than "##any" I must admit I am not an XML guru.

Regards
Andy

> Behalf Of Paul Kyzivat
> Sent: 02 October 2011 18:24
> To: [email-masked]

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 5 Oct 2011 15:28:15 +0530

Andy,

I just followed the same approach as it is defined in RFC 6120. RFC 6120
uses <xs:any namespace='##other' and so used the same.
I am not an XML guru either.

Regards,
Ram

> Behalf Of Hutton, Andrew
> Sent: Monday, October 03, 2011 10:08 PM
> To: Paul Kyzivat; [email-masked]
> I was also wondering why "<xs:any namespace='##other' .../>" is
> specified rather than "<xs:any namespace='##any' .../>".
> 
> Is there a good reason why we need to use "##other" rather than
"##any"
> I must admit I am not an XML guru.
> 
> Regards
> Andy
> 
> 
> > > The schema for<session/>, for example, with the above approach
will
> > be:

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 6 Oct 2011 17:06:40 +0200

Hi,

I believe there are no outstanding objections to these items so can the editors go ahead and incorporate these changes in their next update.

With regard to the discussion on extension data representatives I believe consensus is to go with the approach as described in Ram's e-mail on the 2011-09-26 which gave this example:

The issue of whether to include a statement indicating that elements from different/unknown namespaces is a separate issue and so far I think the balance is towards not including such a statement.

Regards
Andy Hutton (as chair).

> Sent: 23 September 2011 17:00
> To: [email-masked]
> Subject: [siprec] Consensus calls from session 2
> 
> 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: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 12 Oct 2011 14:17:17 +0530

In the last interim there was a *consensus* to have <nameID> xml element
(as shown below) in the metadata document to indicate multiple name/AoR
pairs. However there was a comment to clarify on the need for language
attribute in XML document. 

Xml:lang is a special attribute may be inserted in documents to specify
the language used in the contents and attribute values of any element in
an XML document. More information at section 2.12 of
http://www.w3.org/TR/REC-xml/

Some of the SIP RFC like RFC 3680 already uses xml:lang for display-name
which is what we also need here.

So I am planning to make this as optional attribute following the
similar approach as done in RFC 3680.

The schema for nameID would look as:

<xs:complexType name="nameID">
  <xs:sequence>
     <xs:element name="name" type="xs:string"
        minOccurs="0" maxOccurs="1"/>
     <xs:element name="aor" type="xs:anyURI"
       maxOccurs="1"/>
  </xs:sequence>
  <xs:attribute ref="xml:lang" use="optional"/>
</xs:complexType>

Example is

<nameID>
   <aor>sip:[email-masked]</aor>
   <name xml:lang="it">Alice Smith</name>
 </nameID

Regards,
Ram

> Sent: Thursday, October 06, 2011 8:37 PM
> To: Elwell, John; [email-masked]
> Subject: [siprec] Consensus calls from session 2 - Success
> 
> Hi,
> 
> I believe there are no outstanding objections to these items so can
the
> editors go ahead and incorporate these changes in their next update.
> 
> With regard to the discussion on extension data representatives I
> believe consensus is to go with the approach as described in Ram's e-
> mail on the 2011-09-26 which gave this example:
> 
> The issue of whether to include a statement indicating that elements
> from different/unknown namespaces is a separate issue and so far I
> think the balance is towards not including such a statement.
> 
> Regards
> Andy Hutton (as chair).
> 
> 
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 12 Oct 2011 14:17:12 -0700

Hi Ram,

In your description and schema, it seems xml:lang is an attribute of
"nameID"; however, I think the intent is to have it be an attribute of
"name", isn't it?
If this is true, then the example is fine, but the XML schema looks
incorrect to me. 

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ram Mohan R (rmohanr)
> Sent: Wednesday, October 12, 2011 1:47 AM
> To: Hutton, Andrew; Elwell, John; [email-masked]
> Cc: Peter Saint-Andre (psaintan)
> Subject: [siprec] xml:lang attribute for <nameID> element ( was
RE:Consensus calls from session 2 -
> Success )

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 13 Oct 2011 12:34:56 +0530

Charles,
You are right. The schema I pasted below has a error as it shows
xml:lang as attribute of nameID. I will change it to as below(again
referred 3680 to derive this):

<xs:complexType name="nameID" minOccurs="0" maxOccurs="unbounded">
 <xs:sequence>
    <xs:element name="aor" type="xs:anyURI" minOccurs="0" maxOccurs="1"
/>
    <xs:element name="name" minOccurs="0" maxOccurs="1">
      <xs:complexType>
       <xs:simpleContent>
        <xs:extension base="xs:string">
         <xs:attribute ref="xml:lang" use="optional"/>
        </xs:extension>
       </xs:simpleContent>
      </xs:complexType>
     </xs:element>
 </xs:sequence>
</xs:complexType>
              
Let me know if this schema is correct.

Thanks,
Ram

> From: Charles Eckel (eckelcu)
> Sent: Thursday, October 13, 2011 2:47 AM
> To: Ram Mohan R (rmohanr); Hutton, Andrew; Elwell, John;
> [email-masked]
> Subject: RE: [siprec] xml:lang attribute for <nameID> element ( was
> RE:Consensus calls from session 2 - Success )
> 
> Hi Ram,
> 
> > the language used in the contents and attribute values of any
element
> in
> > > > - List of SSRCs to be part of the association between
participant
> > and

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Oct 2011 13:38:13 -0400

I think it would be possible to make the aor be an attribute of nameID, 
rather than an element. E.g.

<nameID aor="sip:[email-masked]">
    <name xml:lang="it">Alice Smith</name>
  </nameID

This could then be shortened when there is no display name, to:

<nameID aor="sip:[email-masked]"/>

The xml experts will have to weigh in on the stylistic merits one one 
vs. the other.

Regarding the specification of the xml language - is it really 
necessary? The value will presumably come out of a sip message, and 
AFAIK there is no way to specify the language used in the sip headers. 
(Accept-Language and Content-Language both apply to the *body* of the 
message, not the headers.)

	Thanks,
	Paul

On 10/13/11 3:04 AM, Ram Mohan R (rmohanr) wrote:
>> Subject: RE: [siprec] xml:lang attribute for<nameID>  element ( was
>>> Subject: [siprec] xml:lang attribute for<nameID>  element ( was
>>> In the last interim there was a *consensus* to have<nameID>  xml
>> element
>>>>> - Structured<nameId/>  element for use within a<participant/>
>>>> element

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 14 Oct 2011 10:07:02 +0530

Hi Paul,
inline

> Sent: Thursday, October 13, 2011 11:08 PM
> To: [email-masked]
> Subject: Re: [siprec] xml:lang attribute for <nameID> element ( was

This is nice suggestion and it optimizes the xml by a few bits. I am ok
incorporate this. I am not sure about stylistic merits and guess we
don't need to bother much.

> message, not the headers.)

I don't have any strong inclination to keep xml:lang. I looked at
examples of RFC (like RFC 3680) that has encoded display-name in XML and
found that they use xml:lang. As I mentioned below it gives an advantage
in specifying the language used. Of course this is completely optional
in the schema I proposed and If an SRC cannot determine it can always
can choose not to have this attribute.

Regards,
Ram

> >>> Some of the SIP RFC like RFC 3680 already uses xml:lang for
> display-
> >> name
> >>>> believe consensus is to go with the approach as described in
Ram's
> >> e-