Subject: RE: [Simple] The difference between RLS and Presence subscriptions

From: <[email-masked]>
Date: Thu, 11 May 2006 08:12:30 +0200

________________________________________
>From: Gadigeppa Malagund [mailto:[email-masked]] 
>Sent: Thursday, May 11, 2006 7:23 AM
>To: Noga Tor
>Cc: [email-masked]
>Subject: Re: [Simple] The difference between RLS and Presence
subscriptions
>
>Hi,
>
>RLS subscription request has "Supported: eventlist" where as presence
doesn't.
>
>Regards,
>Gadi
>On 5/10/06, Noga Tor <[email-masked]> wrote:
>Hi 
> 
>I was wondering in what way you can tell if a certain subscription is a
Presence Subcription or an RLS Subscription.
>is there any indicator? is it done by the uri in the "TO: " header? and
if so, in what way? 
>Thanks
>Noga

Adam Roach has written here in [email-masked] something about it few
weeks ago:

<forwarded-message>
-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Monday, April 24, 2006 7:16 PM
To: Peknik Silvestr
Cc: [email-masked]
Subject: Re: [Simple] draft-ietf-simple-event-list: identifyinglist
subscriptions

[email-masked] wrote:
> As mentioned in the draft, SIP URI does not indicate whether it
belongs
> to list of resources or to single resource. Can I assume that
Supported:
> eventlist header means that the subscription is a list subscription,
or
> can it happen that also subscription to single resource contains
> Supported: eventlist?

The "Supported: eventlist" header field in the request simply means that
the client *understands* list subscriptions. It has no implication
regarding whether the client expects the indicated resource to be a list
or not.

So, the statement is even stronger than you put it: it's not just that a
subscription to a single resource *CAN* contain "Supported: eventlist"
-- it's that it *MUST* contain "Supported: eventlist" if the subscriber
understands the event list format. (I'm using this "must" as a "this is
the only way, in my opinion, a reasonable implementation can behave,"
not as a standards statement. The specification would technically allow
the client to pick and choose which subscriptions to indicate event list
support -- but not indicating support for event lists would always make
things work worse, and never better).

> This differentiation is needed if the server
> handles both subscriptions to list and subscriptions to single
resources

No, it's not.

It *is* true that the server needs to know whether a subscription is to
be treated as a list subscription or as a subscription to a single
resource.

This is exactly the same statement that a terminating MTA needs to know
whether an email message is intended for a single account or for a
mailing list.

In both cases, the server knows this *independent* of what the client
sends. The server knows whether it's a single resource or whether it's a
list because it's *provisioned* to know which URIs (or email addresses)
correspond to single resources and which URIs (or email addresses)
correspond to lists.

/a

</forwarded-message>

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