Subject: RE: [Simple] FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt

From: "Shetti Shrinivas-Q16945" <[email-masked]>
Date: Tue, 13 Jun 2006 16:00:45 +0800

thanks Gadi,
 
So, I assume that "there is no harm including 'Require: eventlist' in
the SUBSCRIBE, when UAC knows the request URI is a list URI."
 
Can we have this spec updated to indicate the above, rather than
discouraging 'Require' header usage altogether in SUBSCRIBE request?
 
Request spec authors to kindly comment on this.
 
best regards,
Shetti

________________________________

From: Gadigeppa Malagund [mailto:[email-masked]] 
Sent: Tuesday, June 13, 2006 12:03 PM
To: Shetti Shrinivas-Q16945
Cc: [email-masked]
Subject: Re: [Simple] FW: clarification regarding 'Require' header usage
in draft-ietf-simple-event-list-07.txt

Your suggestion is appropriate and enhances performance of the n/w.

When "Supported: eventlist" is included in subscribe, proxy by default
forwards request to 1-1 presence server depending on "Event: presence".
For this if request URI is Group URI, then proxy gets "404 not found"
response from the 1-1 PS.
Proxy sees whether there is header "Supported: eventlist" and then
forwards to RLS.

So if "Require: eventlist" is included then proxy can directly forward
this request RLS.

So this RECOMMENDTION is not specific to presence group subscribe
however more to do with usage of "Require" header by the client.

Note that incoming NOTIFYs from RLS have MUST "Require: eventlist"
header NOT "Supported"

Regards,
Gadi

On 6/13/06, Shetti Shrinivas-Q16945 <[email-masked]> wrote: 

	can some one please clarify this?

________________________________

	From: Shetti Shrinivas-Q16945 
	Sent: Friday, June 09, 2006 2:51 PM
	
	To: [email-masked] '
	Cc: Kelley Sean-Q12059
	
	Subject: FW: clarification regarding 'Require' header usage in
draft-ietf-simple-event-list-07.txt

	In the scenario I've mentioned, the assumption is that  UACs do
have knowledge about whether they are subscribing to list URI or NOT. 
	So, is there any harm if  UAC uses  'Require:eventlist', when
it knows that the request URI is a list URI?

	thanks,
	Shetti

________________________________

	From: Shetti Shrinivas-Q16945 
	Sent: Friday, June 09, 2006 2:12 PM
	To: [email-masked]'
	Cc: Kelley Sean-Q12059
	Subject: clarification regarding 'Require' header usage in
draft-ietf-simple-event-list-07.txt

	hi,
	above draft has following statement in section 4.2
	
------------------------------------------------------------------------
	
	   Including "eventlist" in a "Require" header field in a
SUBSCRIBE
	   request serves no purpose except breaking interoperability in
certain
	   cases, and is consequently NOT RECOMMENDED.
	
------------------------------------------------------------------------
	Can anyone clarify why do we discourage use of 'Require' header?
	My perception about this header being used in SUBSCRIBE is that,
it is not going to cause any harm or issue. I might be missing
something.
	
	I have following scenario in mind.
	All the presence SUBSCRIBE messages land at a proxy. The proxy
server decides to route the request to either 'RLS server' or 1-1
presence server.
	
	Now, if client can use 'Require: eventlist', this is definite
indication for the proxy to route the request to RLS server. Rest of the
subscriptions can go to 1-1 presence server.
	thanks and best regards,
	Shetti

	_______________________________________________
	Simple mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/simple

--  
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Adam Roach <[email-masked]>
Date: Tue, 13 Jun 2006 15:09:08 -0500

The intention of the passage that Shetti cites below is very much that 
client are advised not to sent "Require: eventlist" under any circumstances.

Ignoring SIP for a few moments: when you design a network with lists of 
resources treated as a whole, there are two possible places you can 
require knowledge that any particular resource is a list: either in the 
network or in the client. An example of the former is email lists (when 
you send email to a list alias, your client doesn't know that it is a 
list alias).

When we were designing the event list extension, we felt that the email 
model -- in which the network knows which resources are lists -- was 
more flexible for network administrators.

Your proposal ends up combining the disadvantages of both schemes, while 
adding an additional layer of fragility: both the client *and* the 
network need to know, a priori, whether a resource is a list. This makes 
provisioning of services brittle (since you need to ensure that both 
ends agree on whether a URI refers to a scalar or a vector). Any 
mismatch simply results in a failure to operate.

I understand the architecture you describe -- in which the RLS is at a 
different server than a non-RLS notifier. There are several *far* better 
ways to perform the de-multiplexing described.

The obvious example, following in the spirit of RFC 3087, is to use the 
Request-URI. Keep in mind that this is all according to site-local 
convention, and not subject to standardization. One example of such a 
scheme would be to prefix the user-portion with the five characters 
"list-" for all list resources. The other would be to use a 
list-specific authority portion for the lists (e.g. 
"sip:[email-masked]" for a non-list resource, 
"sip:[email-masked]" for a list resource -- keeping in mind 
that the NAPTR records for "example.com" and "lists.example.com" can 
resolve down to the same IP address if that suits your deployment better).

I will reiterate that these conventions are exactly that -- site-local 
conventions followed by the operator when provisioning resources. I 
speak with considerable experience when I assert that it is quite easy 
to design products that handle such site-local conventions for the 
purposes of de-multiplexing types of requests in an efficient manner.

/a

Shetti Shrinivas-Q16945 wrote:
> *From:* Gadigeppa Malagund [mailto:[email-masked]]
> *Sent:* Tuesday, June 13, 2006 12:03 PM
> *To:* Shetti Shrinivas-Q16945
> *Cc:* [email-masked]
> *Subject:* Re: [Simple] FW: clarification regarding 'Require' header 
> usage in draft-ietf-simple-event-list-07.txt
>
> On 6/13/06, *Shetti Shrinivas-Q16945* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     *From:* Shetti Shrinivas-Q16945
>     *Sent:* Friday, June 09, 2006 2:51 PM
>
>     *To:* [email-masked] <mailto:[email-masked]>'
>     *Cc:* Kelley Sean-Q12059
>     *Subject:* FW: clarification regarding 'Require' header usage in
>     So, is there any harm if  UAC uses  'Require:eventlist',
>     when  it knows that the request URI is a list URI?
>      
>     thanks,
>     Shetti
>
>     *From:* Shetti Shrinivas-Q16945
>     *Sent:* Friday, June 09, 2006 2:12 PM
>     *To:* [email-masked] <mailto:[email-masked]>'
>     *Cc:* Kelley Sean-Q12059
>     *Subject:* clarification regarding 'Require' header usage in
>        Including "eventlist" in a "Require" header field in a SUBSCRIBE
>        request serves no purpose except breaking interoperability in certain
>     My perception about this header being used in SUBSCRIBE is that, it is not going to cause any harm or issue. I might be missing something.
>
>     All the presence SUBSCRIBE messages land at a proxy. The proxy server decides to route the request to either 'RLS server' or 1-1 presence server.
>
>     Now, if client can use 'Require: eventlist', this is definite indication for the proxy to route the request to RLS server. Rest of the subscriptions can go to 1-1 presence server.
>
>     thanks and best regards,
>
>     Shetti
>
>
>     [email-masked] <mailto:[email-masked]>