[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Simple] Question on draft-ietf-simple-event-list-07.txt
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: haris.zisimopoulos at vodafone.com
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple