Subject: [Sipping] FEEDBACK NEEDED BY MAR 16: proposed reg-event format

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Mar 2004 00:24:49 -0500

Folks,

During the SIPPING meeting at IETF, I talked about the options for 
handling contact header extensions when transported in the reg-event 
package. I proposed three approaches:

1. Keep params element, its ugly but works – we don’t want to change at 
this stage

2. Define an <unknown-boolean>, <unknown-int>, etc. elements and allow 
as Contact children
   * If a real extension is defined, data could be in two places

3. Use XML extensions for unknown data
   * Reg event notifications won’t contain data not understood by the server
   * Similar to discussions in SIMPLE on prescaps

The group consensus was for option 2, but there was some debate about 
whether this needed to be typed (i.e., <unknown-int> or just <unknown>). 
I took an action item to get together with Paul Kyzivat and Rohan Mahy, 
the participants in the debate, and come to agreement on the format, and 
then bring to the list for final consensus.

The three of us have consensus on a form that is untyped, which would 
look something like this:

<unknown-param name="foo">bar</unknown-param>

So, if you had a REGISTER like this:

REGISTER sip:[email-masked] SIP/2.0
    Via: SIP/2.0/UDP pc34.bar.com;branch=z9hG4bKnaaff
    From: sip:[email-masked];tag=99a8s
    To: sip:[email-masked]
    Call-ID: [email-masked]
    CSeq: 9976 REGISTER
    Contact: sip:[email-masked];audio;video="false";+param="<val>"

Your XML in the NOTIFY would be:

<?xml version="1.0"?>
    <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
                 version="1" state="partial">
      <registration aor="sip:[email-masked]" id="a7" state="active">
        <contact id="76" state="active" event="registered"
                 duration-registered="0">
           <uri>sip:[email-masked]</uri>
           <unknown-param name="audio"/>
           <unknown-param name="video">false</unknown-param>
           <unknown-param name="+param">&lt;val&rt;</unknown-param>
        </contact>
      </registration>
    </reginfo>

Note that, in the case of a callee-cap paramter that is a string, as is 
the +param parameter above, the value of the parameter has angle 
brackets (this is all in callee caps). That means that, when translated 
into xml, the angle brackets are escaped.

The reason we decided that typing was not needed was that in most cases 
you couldn't determine typing if the parameters are unknown. In the case 
of callee caps, the typing is determined from the value of the parameter 
anyway, so there is no need to convey the type in addition to the value.

As I mentioned during the meeting, the rfc-editor is awaiting my final 
changes to the specification before publication. As a result, time is 
essential here. I'd like to ask for comments by Tuesday, March 16. If 
there are no comments or concerns I will go ahead and have these changes 
put into the specification.

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