There was also an example given in RFC 4662 in Section 6 at Page 20..
3. As is required by RFC 3265 [2], the RLS sends a NOTIFY immediately
upon accepting the subscription. In this example, we are assuming that
the local RLS is also an authority for presence information for the
users in the "vancouver.example.com" domain. "*********The NOTIFY
contains an RLMI document describing the entire buddy list (initial
notifies require full state)*********", as well as presence information
for the users about which it already knows.
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-frie...@pres.vancouver.example.com"
version="1" fullState="true">
<name xml:lang="en">Buddy List at COM</name>
<name xml:lang="de">Liste der Freunde an COM</name>
<resource uri="sip:b...@vancouver.example.com"">
<name>Bob Smith</name>
<instance id="juwigmtboe" state="active"
cid="buz...@pres.vancouver.example.com"/>
</resource>
<resource uri="sip:d...@vancouver.example.com">
<name>Dave Jones</name>
<instance id="hqzsuxtfyq" state="active"
cid="zvs...@pres.vancouver.example.com"/>
</resource>
<resource uri="sip:e...@dallas.example.net">
<name>Ed at NET</name>
</resource>
<resource uri="sip:adam-frie...@stockholm.example.org">
<name xml:lang="en">My Friends at ORG</name>
<name xml:lang="de">Meine Freunde an ORG</name>
</resource>
</list>
In the above example List "adam-budd...@pres.vancouver.example.com"
contains members as
sip:b...@vancouver.example.com,
sip:d...@vancouver.example.com,
sip:e...@dallas.example.net and
sip:adam-frie...@stockholm.example.org
Not sure why RFC mandates/recommends to keep the entire buddy list info
in the first NOTIFY..
-----Original Message-----
From: simple-boun...@ietf.org [mailto:simple-boun...@ietf.org] On Behalf
Of Vavilapalli Srikanth-A19563
Sent: Friday, April 09, 2010 12:38 PM
To: Pandurangan R S; sim...@ietf.org
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 -
ResourceList Subscription
Forwarding to SIMPLE mailing list...
-----Original Message-----
From: Pandurangan R S [mailto:pandurangan....@gmail.com]
Sent: Friday, April 09, 2010 12:07 PM
To: Vavilapalli Srikanth-A19563
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Question on RFC 4662 - Resource List
Subscription
RFC 4662 states
The third mandatory attribute is "fullState". The "fullState"
attribute indicates whether the NOTIFY message contains information
for every resource in the list. If it does, the value of the
attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The
first NOTIFY sent in a subscription MUST contain full state, as must
the first NOTIFY sent after receipt of a SUBSCRIBE request for the
subscription.
Why is it a required that first NOTIFY contains information for every
resource in the list? I believe it can have a initial information (which
tells the subscriber to get rid of any old info) and then build upon the
data using further NOTIFYs.
Any interop problems if the "fullState" flag is interpreted as
"initialState" flag?
On Fri, Apr 9, 2010 at 10:48 AM, Vavilapalli Srikanth-A19563
<srikan...@motorola.com> wrote:
> Hi
>
> I have a question related to first NOTIFY being generated for a
> Resource List Subscription assuming where the all the entities support
> only unreliable UDP transport and message size is limitied by path MTU
> size (because of for ex. No support for UDP fragmentation by the
> intermediate routers on that network)..
>
> As per RFC 4662, The first NOTIFY sent in a subscription MUST contain
> full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE
> request for the subscription. And the "fullState" attribute indicates
> that the NOTIFY message contains information for every resource in the
> list..
>
> Assuming a user has subscribed to his buddy list of 100 to 150 users
> and MTU size is defined as 1500 Bytes, How to fit the "full state"
> information (which contains the RLMI with all the the user URIs with
> the state of subscription + ZERO or more presence states of each
> resource in the list) in the first NOTIFY sent towards subscrier?
>
> Are there any well defined schemes to split such a BIG NOTIFY in to
> multiple NOTIFYs without violating the above RFC 4662 requirement?
>
> Regards
> Srikanth
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Simple mailing list
sim...@ietf.org
https://www.ietf.org/mailman/listinfo/simple
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
