Subject: [Sipping] Clarification regarding RFC 3680

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Mon, 10 Jan 2005 15:53:11 -0800

Hi:

RFC 3680 allows for user agents to SUBSCRIBE for registration events. The payload data for the same allows the user agent that registered for this event package, access almost all the important aspects of the Registration: AOR registered, the Call-Id used, the contact, the CSeq number, q value, the duration et al. However, there are a couple of pieces of information that might be useful for certain applications: the from user (useful in case of third party registrations) and the user-agent (the make/model information provided by UA's in this header may be useful for some applications). I couldn't find anything in the standard xml schema (apart from using some private extensions) that could be used for providing this information. Is this something that being considered to be included in the base document ? 

Venkatesh

_______________________________________________
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: Tue, 11 Jan 2005 09:04:03 -0500

Venkatesh,

You are right that there is currently no provision for representing the 
information you ask about. There is also other information (that I think 
is likely to be more important than what you are asking for) that isn't 
available. I previously submitted a draft:

    draft-kyzivat-sipping-gruu-reg-event-01

to deal with part of that. However it has so far met with underwhelming 
interest. Along the way there were suggestions that there might be other 
information that also ought to be included. But what came up in 
discussion drew even less interest.

If you can stir up interest for other things, they could be combined 
into one extension proposal.

OTOH, I am dubious about adding the particular items you suggest. The 
reason is because they are state that a registrar currently does not 
need to store. Of course it would still be possible to provide a way to 
represent it, while leaving the decision to return it to the registrar. 
But then a subscriber could never count on getting this information.

The extension for gruu is different in this regard. It would be returned 
if the registrar supports gruu and if a gruu has been assigned. So its 
availability is coupled with the need for it.

	Paul