Subject: [Simple] Questions on http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-07.txt

From: "Yannis Pavlidis" <[email-masked]>
Date: Fri, 5 Aug 2005 10:42:26 -0700

Hi,

I wanted to make some comments regarding this draft.

1.	It is not clear in this document what the duration should be of
the back end subscriptions placed from the RLS to the Presence
Server(s). In the example while the event list subscription has a
duration of 7200 the back end subscriptions have a duration of 3600.
This will result in wasting resources in the RLS e.g. the event list
subscription will remain active for one more hour while the back end
subscriptions have been terminated. It would be reasonable to assume
that the duration of the back end subscriptions is the same with the
duration of the event list subscription (at least on the establishment
part as a PS may reduce the subscription duration of the back end
subscription). What are your thoughts?
2.	According with the text in section 4.1

	a.	Message flow  7 should not contain a require header as
ed is not a resource list
	b.	Message flow 10 should contain a require header as
adam-friends is a resource list

3.	The example in the draft assumes a co-location of a PS and RLS
server. What happens when in a domain they are separated (a separate RLS
and PS instance)? How is the request for a specific user will go to the
PS (flow 5) and how a request for a resource list will go to the RLS
(flow 9)?

Thanks,

Yannis.

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 08 Aug 2005 18:05:56 -0500

Yannis Pavlidis wrote:

>       Server(s). In the example while the event list subscription has
>       a duration of 7200 the back end subscriptions have a duration of
>       3600. This will result in wasting resources in the RLS e.g. the
>       event list subscription will remain active for one more hour
>       while the back end subscriptions have been terminated. It would
>       be reasonable to assume that the duration of the back end
>       subscriptions is the same with the duration of the event list
>       subscription (at least on the establishment part as a PS may
>       reduce the subscription duration of the back end subscription).
>       What are your thoughts?
>

Your assertion isn't exactly correct, as any failure on the back-end 
will trigger notification to the ultimate subscriber letting them know 
that one of the resources in the list has gone away:

   If an instance of a resource was previously reported to the
   subscriber but is no longer available (i.e.  the virtual subscription
   to that instance has been terminated), the resource list server
   SHOULD include that resource instance in the meta-information in the
   first NOTIFY message sent to the subscriber following the instance's
   unavailability.  The RLS MAY continue to do so for future
   notifications.

In any case, the handling of back-end subscriptions is completely up to 
the implementation (modulo some of the security issues discussed in the 
draft), including duration of subscriptions. If you have a valid network 
purpose to making those subscriptions 10 seconds, go ahead. If you think 
8 hours is a better choice, feel free. (Both of those values are 
dubious, by the way). If you think you want to make them match the 
front-end subscriptions, nothing stops you. Make it random. Choose 
100*pi. This is where you, as an engineer, add value. If we wanted 
everything to work exactly the same, then the IETF would be creating and 
standardizing software instead of protocol specifications.

>
>    1. According with the text in section 4.1
>          1. Message flow  7 should not contain a require header as ed
>             is not a resource list
>          2. Message flow 10 should contain a require header as

Good catch. I will fix these errors in auth48.

>    1. The example in the draft assumes a co-location of a PS and RLS
>       server. What happens when in a domain they are separated (a
>       separate RLS and PS instance)? How is the request for a specific
>       user will go to the PS (flow 5) and how a request for a resource
>       list will go to the RLS (flow 9)?
>

That's a network architecture question, not a protocol question -- and a 
lot of that comes down to how you otherwise design your network. At a 
high level, once you start using different servers for different 
functions within a single domain (and such is usually the case), you 
need to figure out how you're going to perform that distribution. Event 
lists are no exception.

/a