Subject: Re: [Sipping] WGLC draft-ietf-sipping-reg-event-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 02 Nov 2002 15:26:54 -0500

inline.

Brian Stucker wrote:
> I am seriously confused....
> 
> Can someone explain to me why we're suggesting that we do the following:
> 
> 1. Client takes the information necessary to send a registration message 
> and encodes it into a SIP message for transport.
> 
> 2. Registrar decodes the registration, process it, sees that there is a 
> subscription for this user's registration and so...
> 
> 3. RE-ENCODES the registration information into XML, even though the 
> client that sent us the registration already went to the trouble of 
> encoding nearly all of the information we're interested in (which makes 
> it take up extra bytes), and sends it to the interested party.
> 
> 4. Interested party decodes the NOTIFY body, and does whatever it wants.
> 
> Instead of going through all this trouble, why are we not following the 
> example of REFER and using a sipfrag? 

Its a good question. We never had any real debate on this; it was just 
my general inclination to define data abstractions, so that these things 
could be decoupled if needed. For example, using the events package to 
subscribe to h323 registration status. Not saying I'm itching to do 
that, of course...

One concrete point to make is that the notifications contain a bunch of 
info thats NOT in the register message itself. For example, indicating 
that this is a refresh as opposed to a new subscription. We could add 
that as a new sip parameter, but it has no meaning in the context of 
actual SIP registrations. That should be telling you that there is an 
additional layer here that takes the register messages as input, adds 
additional data, and generates the results as output. The input and 
output are not the same; they are used for different purposes.

A similar concept exists in presence. You could argue that a presence 
doc should look like a registration, for the same reasons. But, there is 
this nice layer of abstraction that decouples them in a way thats good. 
Now, of course, Paul K will pipe up and disagree, but I still stand by 
this design approach.

That said, it is just a design approach, and technically, I can think of 
nothing that will fail by using a sipfrag approach. I just prefer the 
XML way. sipfrag is probably more compact though, that is true too. 
Compression may make this point moot where it matters.

So, I welcome other opinions on this topic so that we may gauge some 
consensus.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[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: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Nov 2002 11:53:02 -0500

> Now, of course, Paul K will pipe up and disagree, but I still stand by

No, I have changed my opinion.

I now think that presence is in the process of rendering registration obsolete. If the current notions of presence had existed at the time SIP was first defined, I think it would have been used instead of registration. But as things happened, it is now an important legacy feature, and likely will never go away, though it may diminish in importance.

Presence is (potentially) richer than registration, so I don't want to force it into the mold of registration. But I do think presence should encompass everything in registration.

	Paul