Subject: [Simple] Question on simple-event-list-07

From: "Zisimopoulos, Haris, VF-Group" <[email-masked]>
Date: Wed, 17 Aug 2005 17:51:42 +0100

Hello,

In section 4.5 of draft-ietf-simple-event-list-07 it is stated that: 

"The "state" attribute of each instance of a resource in the meta-
information is set according to the state of the virtual subscription.
The meanings of the "state" attribute are described in RFC 3265 [2]"

Does this means that there is 1-to-1 mapping between the
"Subscription-state" header of the NOTIFY request of the back-end
subscription and the "state" attribute of the RLMI? In that case how
will be handled back-end subscriptions that do never get a NOTIFY? I am
particularly looking at two cases:

1. The PS of the back-end subscription does never respond (eg due to
failure) 2. There is a local policy in the RLS that prohibits the RLS to
perform more than a certain number of back-end subscriptions per
subscriber.

What are the appropriate values that the "state" attribute of the RLMI
should take in that case? Is there another value necessary for the
enumeration of the "state" element something like "notperformed" for
example?

Best regards,
Haris

Haris Zisimopoulos
Group Research & Development - UK
Vodafone Group Services Ltd

E-mail: [email-masked]

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

---

From: Adam Roach <[email-masked]>
Date: Thu, 18 Aug 2005 12:13:41 -0500

Zisimopoulos, Haris, VF-Group wrote:

>subscription and the "state" attribute of the RLMI?
>

They are semantically equivalent. This isn't quite the same thing as 
having a one-to-one mapping, since back-end subscriptions can take the 
form of any arbitrary protocol (not just SIP). In any case, the actual 
linkage between any back end subscriptions -- even if they are SIP -- 
and the resource list subscription is a matter of implementation, not 
standardization. It is certainly *sensible* that you would simply pass 
these states through, but there may be other reasonable things to do as 
well.

>In that case how will be handled back-end subscriptions that do never get a NOTIFY?
>

The  most reasonable thing to do would be to return an RLMI document in 
which the "<resource>" element corresponding to that failed subscription 
contains no "<instance>" elements. See, for example, the entries for 
"sip:[email-masked]" and "sip:[email-masked]" 
in step 3 of the example in section 6.

/a