Subject: RE: [Sipping] Problem with reg-event that needs immediate fix

From: "Mary Barnes" <[email-masked]>
Date: Thu, 18 Dec 2003 14:41:31 -0600

We agree that it's better to fix this adding the <uri> element rather than
one of the alternatives.   

Regards,
Mary (and Brian S.)
  
-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thursday, December 18, 2003 11:13 AM
To: sipping
Subject: [Sipping] Problem with reg-event that needs immediate fix

While implementing the sipping reg-event draft, we ran into a serious 
technical problem.

The problem is that the specification has not left sufficient room for 
extensibility within the XML schema. It allows for new information to 
be added to the <registration> element (which describes the AOR), but 
does not allow any additional information to be provided about a 
contact. We ran into this problem because we needed to add path 
information (ala rfc 3327) to the notifications, but this information 
is per contact. There is no way to do this with the current specification.

The essence of the problem is that the contact element has, as 
content, the actual URI. This makes it difficult to add other 
information about the contact. A better approach would have been to 
make the contact element a complex type, which would include an 
element called <uri> that contains the uri.

For example, today we have:

<?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">sip:[email-masked]</contact>
      </registration>
    </reginfo>

whereas it ought to have been:

<?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>
        </contact>
      </registration>
    </reginfo>

The schema for the contact element could then allow for other children 
in other namespaces, giving us the needed extensibility.

Unfortunately, there is other per-contact data we might want to add in 
the not-too-distant future, such as callee-caps information. That kind 
of data would be very useful for presence applications, where the 
presence server could obtain it from the registrar using reg-event.

I believe that this problem is significant enough that we should try 
and address it during auth48. For those of you not familiar with it, 
auth48 is a brief period just before publication of the actual RFC 
where the author can correct typos or minor other problems. It is 
possible, with AD approval, to make more substantive changes as I am 
suggesting (and indeed I already ran this by Allison and she is OK). 
Of course, I still need group consensus on any change. So, here is my 
proposal.

PROPOSAL

My proposal for fixing this, as outlined above, is to modify the XML 
schema. The <contact> element will instead become a complex type. It 
will have, as children, a sequence of <uri> followed by an optional 
element from any other namespace. The <uri> element will contain the 
actual contact URI.

Unfortunately, this proposed solution above is not backwards 
compatible with the current draft.

I considered other solutions as well:

ALTERNATE 1

Modify the schema to allow attributes in the contact element from 
other namespaces. Adds some extensibility, but is very bad for more 
complex data, such as path or callee-cap data. Using attributes for 
that data will require us to define a lot of structure within each 
attribute. This approach is backwards compatible, but not forwards 
compatible. That is, an implementation compliant to the schema before 
this change would reject documents created by an implementation 
compliant to the schema after the change.

ALTERNATE 2

Modify the schema to contain a new element, child to the 
<registration> element. This element would be called "alt-contact", 
and would be defined as I suggest above for contact. Whenever new 
information is needed about a contact, the "alt-contact" element would 
be present, and contain that extension data. The document would also 
still contain a contact element, repeating the URI and other 
attributes. This would provide forwards and backwards compatibility, 
at the expense of a horrible hack that would repeat a lot of 
information in the document.

I found neither of the two alternatives very palatable, which is why 
my proposal is to fix this now, and do it properly, while we still can.

Please provide input on the proposal ASAP. I'd like to come to 
consensus in the next week or so (before everyone disappears for 
vacations).

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