[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Simple] Question on simple-event-list-07
Adam,
Thanks for the clarification. What I am worried about related to that is
also the fact a very large RLMI document can become an overkill for
wireless terminals memory, UI processing etc. Taking into account that
the "resource list" can potentially be "shared document" manipulated
also with XCAP by multiple clients this can also be a kind of DoS attack
for example in open chat group situations (with some mobile terminals).
Therefore I was wondering if there is any alternative to transfer the
whole rlmi in one single NOTIFY as recommended in the last paragraph of
section 4.5? Can it be the case that for the "non-performed" back end
subscriptions you send them in a separate NOTIFY or you don't send them
at all?
Any ideas?
Best regards,
Haris
-----Original Message-----
From: Adam Roach [mailto:adam at nostrum.com]
Sent: 18 August 2005 18:14
To: Zisimopoulos, Haris, VF-Group
Cc: simple at ietf.org
Subject: Re: [Simple] Question on simple-event-list-07
Zisimopoulos, Haris, VF-Group wrote:
>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?
>
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:ed at dallas.example.com" and "sip:adam-friends at stockholm.example.com"
in step 3 of the example in section 6.
/a
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple