Subject: Re: [Sipping] GRUU support in reg event package

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Oct 2004 17:01:27 -0400

Hisham,

I realized I never responded to your points here.

	Paul

[email-masked] wrote:
> 
>>Jonathan has expressed interest in including info on any Path header 
>>that might be associated with a Contact.
>>
>>- Do you think info on the Path header should be returned
>>   in reg event notifications?
> 
> Well, the Path header contents are useless to the client. I don't know what advantages this will gather.

There is potential use for this by a client, although unnecessary when 
gruus are available.

If one uses the reg event package to learn about registrations, and if 
this provided Path header info, then that could be used to format a 
request so it traverses the same path that a request addressed to the 
AOR would, but supplying the contact address rather than having the home 
proxy pick it. This would permit reaching a contacts that isn't directly 
reachable from the sender.

Suppose the AOR is sip:[email-masked],
and the contact is sip:[email-masked],
and there is an associated Path with sip:sbc.atlanta.com;lr

Then a subscriber could use this information to format a request like:

	INVITE sip:[email-masked]
	Route: sip:atlanta.com;lr
	Route: sip:sbc.atlanta.com;lr
	...

This would have a decent chance of actually making it to Alice's pc.
(Admittedly this is a stretch, and there are other ways to achieve the 
same thing.)

>>At them moment I am not aware of any other registrar state to be 
>>reported, but feel free to point out something I have forgotten.
>>
>>- Are there other extensions to the reg event package that you would 
>>like to see?
> 
> Maybe service-route header? More useful to the client that the Path headers anyway.

The service-route is only useful to the register client, and is provided 
to it via the register. This client doesn't need to subscribe to the reg 
event package to get this information. And the information isn't useful 
to any other client.

So I find reporting on Path at least potentially useful, while reporting 
on Service-Route doesn't seem to be.

> I have a further comment about this draft:
> 
> I think it is a good idea for the draft stress that this is an extension and how a client should behave when it receives the notifications with XML elements it does not understand (ignore them, for example). A section on registrar behaviour is beneficial as well.

OK, that seems reasonable.

	Thanks,
	Paul

_______________________________________________
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: Wed, 06 Oct 2004 12:03:02 -0400

Paul Kyzivat wrote:
>> I think it is a good idea for the draft stress that this is an 
>> extension and how a client should behave when it receives the 
>> notifications with XML elements it does not understand (ignore them, 
>> for example). A section on registrar behaviour is beneficial as well.
> 

I thought further about this, and have questions:

It does no good for an extension to provide special instructions for how 
the extension should be supported by something that doesn't support the 
extension. In fact RFC 3680 already gives very clear instruction that 
unknown values in the extension entities MUST be ignored. So that is 
already covered.

What probably does make sense is just to point out that fact - that this 
extension is indeed backward compatible because of the rules in 3680.

Regarding registrar behavior - nominally the registrar isn't involved at 
all. The NOTIFIER is presumably in some close relationship with the 
registrar. It may make sense to have the kind of sections that typically 
appear in event packages:

- Notifier Processing of SUBSCRIBE Requests
- Notifier Generation of NOTIFY Requests
- Subscriber Processing of NOTIFY Requests

Would that cover your concerns?

	Paul