Subject: RE: [Sipping] URGENT: query on another reg-event change

From: [email-masked]
Date: Thu, 19 Feb 2004 10:41:09 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 16.February.2004 20:05
> To: sipping
> Subject: [Sipping] URGENT: query on another reg-event change
> 
> 
> Folks,
> 
> Authors 48 hours have started for reg-event. As you may recall, I had 
> found a fatal problem in the schema design, and there was 
> agreement on 
> the list on a proposal to fix it. While making the changes in the 
> schema, another question came up.
> 
> The question is regarding the "params" attribute of the "contact" 
> element. Currently, this parameter is meant to contain any of the 
> contact parameters not otherwise called out explicitly in other 
> attributes (for example, the q-value is contained in the "q" 
> attribute. 
> So, if I had a contact like this:
> 
> REGISTER
> To: sip:[email-masked]
> Contact: sip:[email-masked];q=1.0;newparam=foo;audio
> 
> then the resulting XML would look like (using the new schema 
> I proposed 
> on the list):
> 
>   <?xml version="1.0"?>
>     <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
>                  version="0" state="full">
>       <registration aor="sip:[email-masked]" id="as9"
>                     state="active">
>         <contact id="76" state="active" event="registered"
>                  duration-registered="7322"
>                  q="0.8" params="newparam=foo;audio">
>            <uri>sip:[email-masked]</uri>
>         </contact>
>       </registration>
>     </reginfo>
> 
> Notice how the contact parameters are basically passed 
> untouched in the 
> "params" attribute. This makes sense if that is the only point of 
> exensibility in the schema. But, now with the structured contact, one 
> could represent these "properly" with formal schema 
> definitions. i.e., 
> if we did a reg-event extension to support caller-prefs, it 
> could look like:
> 
>   <?xml version="1.0"?>
>     <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
>              xmlns:callerprefs="urn:ietf:params:xml:ns:callerprefs"
>                  version="0" state="full">
>       <registration aor="sip:[email-masked]" id="as9"
>                     state="active">
>         <contact id="76" state="active" event="registered"
>                  duration-registered="7322"
>                  q="0.8" params="newparam=foo;audio">
>            <uri>sip:[email-masked]</uri>
>            <callerprefs:audio/>
>            <unknown-param name="newparam>foo</unknown-param>
>         </contact>
>       </registration>
>     </reginfo>

I would remove the params attribute all together and just use the unknown-param element.

> 
> That is, I could instead define a new element called 
> "unknown-param" in 
> reg-event that is used for unknown params, and for those that 
> are known 
> to the server, and for which more structured xml 
> specifications exist, 
> you could have things like <callerprefs:audio>.
> 
> The technical drawback here is that whether a parameter appears in 
> unknown-param or whether its in something like 
> callerprefs:audio depends 
> on whether that particular extension (in this case, callerprefs) is 
> supported by the server. 

The client can examine the namespaces, if callerprefs in not there, then it looks for the parameters in the unknown-param elements. If that namespace is there, then it looks in callerprefs specific extension elements.

I would actually like to suggest a change that makes all the contact params appear as elements, including q. This makes all the contact params sub elements of contact element, which I believe is neat. Using your example above, something like:

   <?xml version="1.0"?>
     <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
              xmlns:callerprefs="urn:ietf:params:xml:ns:callerprefs"
                  version="0" state="full">
       <registration aor="sip:[email-masked]" id="as9"
                     state="active">
         <contact id="76" state="active" event="registered"
                  duration-registered="7322">
            <uri>sip:[email-masked]</uri>
            <q>0.8</q>
            <callerprefs:audio/>
            <unknown-param name="newparam>foo</unknown-param>
         </contact>
       </registration>
     </reginfo>

Perhaps event the duration-registered attribute, if it relies on the expires attribute.

/Hisham

> Another choice is to not even 
> include unknown 
> parameters in the reg-event notifications, however I think 
> thats a bad idea.
> 
> The benefit, however, is that it allows us to provide very structured 
> notifications for contact header field extensions, and it avoids the 
> need for implementing, for example, a caller-prefs parser just to 
> receive notifications about caller preferences parameters - 
> all the data 
> is represented using XML constructs.
> 
> Technically, my preference would be to define the unknown-param in 
> reg-event right now, and have extensions (like callerprefs and gruu) 
> specify xml schema extensions to reg-event for their data.
> 
> Please provide comments on this proposal within the next few days.
> 
> Thanks,
> Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP