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

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

inline.

Brian Stucker wrote:
> Section 4.4:
> 
> Do you think it's a good idea to have the default expiration for the 
> registration, and the subscription to be the same length? I could see 
> situations where this could cause race conditions that would cause 
> NOTIFY messages to intermittently fail to be sent due to the 
> subscription and registration naturally expiring right around the same 
> time.

Normally the subscription won't expire and then be refreshed; it would 
be kept continously alive by sending the refresh before it expires, in 
which case this is a non-issue. If you don't keep your subscriptions 
continously active, you can't complain about missing notifications.

I had received private comments some time back expressing a similar 
concern, worried about some kind of oscillation effect. However, I still 
don't see it practically speaking. Can someone point out a specific case 
that would really arise?

That said, since the cost of cinreasing this duration is zero, I'll do 
it anyway (4200s is my proposal), but I am curious if it is really 
solving a real problem.

> 
> Other comments:
> 
> What exactly is the purpose of having the ID field in the contact 
> portion of the NOTIFY body? Doesn't seem very useful to be a required 
> element. Is there any reason that you would not make this some sort of 
> hash of the contact element data (ie. the contact address itself)? In 
> other words, what does the ID field do for you that simplying keying off 
> the data doesn't, since you can't have two entries with the exact same 
> contact address in the same registration message?

Just makes life easier, thats all. My experience with SIP over time has 
convinced me of the fact that it is a BAD idea to use an arbtirary URI 
as an index, since two URIs could be syntactically different but 
semantically equivalent, making hashing and other indexing approaches 
complicated. Be explicit, thats my aim here. A concrete index makes any 
such URI issues go away.

-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: "Brian Stucker" <[email-masked]>
Date: Sun, 3 Nov 2002 17:59:45 -0600

Seems dangerous more than anything. I'm not concerned if they keep
refreshing the subscription, because that will obviously make the entire
discussion moot.

It's more a case where one end let's the subscription run out, and the other
lets their registration run out, which is not terribly likely (unless you
have bad implementations at either end).

Thanks,

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Saturday, November 02, 2002 2:20 PM
To: Stucker, Brian [NGC:B617:EXCH]
Cc: Rohan Mahy; [email-masked]'
Subject: Re: [Sipping] WGLC draft-ietf-sipping-reg-event-00.txt

inline.

-Jonathan R.

---

From: "Brian Stucker" <[email-masked]>
Date: Sun, 3 Nov 2002 18:14:58 -0600

Thanks Jonathan,

A few points...

Do we really need to add these fields as part of the normal registration
contact line to do this?

I don't see why we can't sipfrag the information, but tack-on information to
the headers as well. I guess the two notions aren't mutually exclusive in my
mind. If you're implementation supports this event package, then your
contact decoder would have extra abilities that a basic registration header
encoder/decoder does not have. Seems straightforward, and there's no reason
that you would have to totally tear the contact line apart to add the
optional fields.

Additionally, although compression will obviously help (as you point out),
if there is less information to compress, that's even better. So, I'm not
sure I'd characterize the use of compression as making this point moot.
Besides, compression can be a very expensive operation, and what's more
important to my mind is that we minimize the amount of work that's required
by the node sending these notifications as much as possible. Reusing the
work of the client that sent the registration in the first place seems like
a very good place to save CPU cycles.

Having to decode the contact information, re-encode it into XML, and then
compress it seems like a step in the wrong direction when you have to scale
this up.

I agree that data-abstraction is a good practice. However, as this event
package is defined, it does not appear to be all that terribly abstracted in
the first place, nor does using a more compact form of encoding prevent
optional attributes. Again, what if you transferred to an H.323 endpoint,
does the REFER body need to support XML? No. XML is good for interoperable
encoding, but you can make very un-abstracted XML, just like you can make
very abstracted serialized objects.

As for presence, that's a little different of a beast. You can interpret all
sorts of actions as feeds for presence, and we already had RFCs around to
tell us how the abstraction should proceed for CPIM interop, etc.

Regards,

Brian Stucker

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Saturday, November 02, 2002 2:27 PM
To: Stucker, Brian [NGC:B617:EXCH]
Cc: Rohan Mahy; [email-masked]'
Subject: Re: [Sipping] WGLC draft-ietf-sipping-reg-event-00.txt

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.