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

From: "Shetti Shrinivas-Q16945" <[email-masked]>
Date: Wed, 14 Jun 2006 13:04:55 +0800

Hi Adam,
Thanks for detailed response. I understand your view point.

The usecase which I have in hand is that the client always knows for
sure that the req-uri is 'eventlist' uri or not. Question of mismatch
doesn't arise here. I am also looking at the other possibility of
indicating it as eventlist uri as per rfc3087.

I am OK with the current text in the spec. The statement doesn't
'forbid' usage of 'Require' header altogether.

*But, I feel that anyone who reads the spec will not understand the real
purpose or reasons for it. Is it possible to put some background in the
next version of the draft spec? that would be of very good help.*

Coming to request URI convention: is it ok to use uri parameters? Like
user=phone type.
For ex:
sip:[email-masked];list=eventlist
OR
sip:[email-masked];eventlist

I am not sure if it is inline with 3087 spec.
Regards,
Shetti

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Wednesday, June 14, 2006 1:39 AM
To: Shetti Shrinivas-Q16945
Cc: Gadigeppa Malagund; [email-masked]; [email-masked];
[email-masked]; Kelley Sean-Q12059
Subject: Re: [Simple] FW: clarification regarding 'Require' header usage
in draft-ietf-simple-event-list-07.txt

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:
> 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] 
> <mailto:[email-masked]>> wrote:
>
>     can some one please clarify this?
>
>
------------------------------------------------------------------------
>     *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
>     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] <mailto:[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] <mailto:[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: Wed, 14 Jun 2006 06:27:16 -0500

Shetti Shrinivas-Q16945 wrote:

>Is it possible to put some background in the next version of the draft spec?
>  
>

Not really. The document is in the RFC Editors' Queue. Substantive 
changes at this point would slow the process down considerably.

>sip:[email-masked];eventlist

No.

SIP URI parameters are controlled by IANA, and require an RFC. See RFC 
3969 and RFC 3427 for details.

/a