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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Feb 2004 13:05:15 -0500

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>

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. 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

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 16 Feb 2004 16:31:15 -0500

> Folks,
[snip]

> specify xml schema extensions to reg-event for their data.
I agree pretty strongly. The more precision and granularity we can give to 
the data model, along with the ability to naturally extend this schema 
without an ever-increasing "garbage can" of opaque data, the better off we 
will be going forward. I don't think it's such a burden for a client to 
have to look in two places to deal with servers that haven't caught up with 
the schema changes.

Dave.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 18 Feb 2004 12:36:51 -0800

Jonathan,

The current rev of the dialog package takes a middle approach.  Rather 
than stick everything in a single string or apply semantics to every 
tag, the target tag (the equivalent of the contact tag in the 
registration package) can have sub-elements for contact parameters

<contact id="123" uri="sip:[email-masked]" state="active" etc...>
   <param pname="actor" pvalue="msg-taker"/>
</contact>

I think this would work just fine for the registration package.

thanks,
-rohan

On Feb 16, 2004, at 10:05 AM, Jonathan Rosenberg wrote:

> 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]
> then the resulting XML would look like (using the new schema I 
> proposed on the list):
>
>  <?xml version="1.0"?>
> Notice how the contact parameters are basically passed untouched in 
> the "params" attribute. This makes sense if that is the only point of 
> 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>.
>
> 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. Another choice is to not even 
> include unknown parameters in the reg-event notifications, however I 
> think thats a bad idea.
>
> receive notifications about caller preferences parameters - all the 
> data is represented using XML constructs.
>