Subject: [Sipping] draft-kyzivat-sipping-gruu-reg-event-03.txt

From: Venkatesh <[email-masked]>
Date: Thu, 4 Aug 2005 04:46:29 -0700

RFC 3680 current allows a UA to subscribe for registration events and get 
notified of any changes in the registration state for a AOR. While it allows 
the UA to receive most of the information contained in the register (the AOR 
being registered, the duration, the CSEQ, the call-id used et al), one of 
the things that might be useful for a UA receiving this information is if 
this registration was a first party or a third party registration and if 
third party who the registering user is. I can think of a couple of use 
cases for this (although there might be a few others):
 1. An application such as shared line appearances might want to use this 
information to decide when to initiate distribution of dialog state to 
various entities and when to stop the same. 
 2. An application might want to provide a UI to the end user to display 
his/her list of active registrations. It might also want to indicate to the 
end user which of the registrations being displayed are his/hers (first 
party) and which of those are from other users he/she has authorized to 
register on his/her behalf.
 I was wondering if others consider obtaining this information useful enough 
and if yes, can the same be enabled as a part of the changes being proposed 
by the gruu-reg-event draft.
 Regards,
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: Thu, 04 Aug 2005 14:38:31 -0400

Venkatesh wrote:
> RFC 3680 current allows a UA to subscribe for registration events and 
> get notified of any changes in the registration state for a AOR. While 
> it allows the UA to receive most of the information contained in the 
> register (the AOR being registered, the duration, the CSEQ, the call-id 
> used et al), one of the things that might be useful for a UA receiving 
> this information is if this registration was a first party or a third 
> party registration and if third party who the registering user is. I can 
> think of a couple of use cases for this (although there might be a few 
> others):
>  
> his/her list of active registrations. It might also want to indicate to 
> the end user which of the registrations being displayed are his/hers 
> (first party) and which of those are from other users he/she has 
> authorized to register on his/her behalf.
>  
> I was wondering if others consider obtaining this information useful 
> enough and if yes, can the same be enabled as a part of the changes 
> being proposed by the gruu-reg-event draft.

There is a problem with this idea: the behavior of a registrar as 
defined in 3261 does not in any way suggest that the registrar retain 
any information about the identity of the identity of the request that 
registers a contact. The notion of first party or third party 
registrations is one that is at most an issue of authorization. Once 
authorized, that knowledge need not be retained.

	Paul

---

From: Venkatesh <[email-masked]>
Date: Sat, 6 Aug 2005 10:13:58 -0700

Hi:
 I was trying to see if adding this information sounded like a good idea to 
others as well for starters :-). The current reg-event package provides 
information somethng like "Someone that I know you have authorized is 
modifying your registrations". I am thinking providing something like "A 
John Doe that you have authorized is modifying your registrations" has more 
value. 
 The registrar by itself might not have any use for this information and 
need not persist this information. It only needs to have access to this 
information when sending out the reg-event. Most of the events generated by 
the registrar are usually when it acts on a REGISTER request. At this point 
it has the AOR it has authenticated. It can simply copy over the same into 
the reg-event. Ofcourse there may be some scenarios where it might generate 
events where it doesnt have access of the AOR (purging registration on timer 
expiry). In these cases, it doesnt need to populate this information as it 
is an action undertaken by it's own.
 Venkatesh

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Aug 2005 12:34:38 -0400

Venkatesh wrote:
> Hi:
>  
> I was trying to see if adding this information sounded like a good idea 
> to others as well for starters :-). The current reg-event package 
> provides information somethng like "Someone that I know you have 
> authorized is modifying your registrations". I am thinking providing 
> something like "A John Doe that you have authorized is modifying your 
> registrations" has more value.
>  
> information when sending out the reg-event. Most of the events generated 
> by the registrar are usually when it acts on a REGISTER request. At this 
> point it has the AOR it has authenticated. It can simply copy over the 
> same into the reg-event. Ofcourse there may be some scenarios where it 
> might generate events where it doesnt have access of the AOR (purging 
> registration on timer expiry). In these cases, it doesnt need to 
> populate this information as it is an action undertaken by it's own.

The assumption that the info is only needed when a registration changes 
it is just wrong. Any time a new subscription is received an initial 
notification must be sent with the status of all the currently 
registered contacts.

Supplying info on an as-available basis seems a sure fire formula for 
failure.

I think if this is going to be added as a capability then it must also 
ammend 3261 to require capturing this information. But I don't think 
that is likely. Maybe others have a different opinion on that.

Personally I don't think there is any particular relevance for this bit 
of information.

	Paul

> Venkatesh
> 
>  
> On 8/4/05, *Paul Kyzivat* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     Venkatesh wrote: