Avasarala Ranjit-A20990 wrote:
> It could be that they did not anticipate the buddy list to very large
> one.
Or it could be that they expected that the implementors would support
TCP, as 3261 requires them to do.
Thanks,
Paul
> Regards
> Ranjit
>
> -----Original Message-----
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> Vavilapalli Srikanth-A19563
> Sent: Friday, April 09, 2010 2:21 PM
> To: Pandurangan R S; sim...@ietf.org
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] [Simple] Question on RFC 4662 -
> ResourceListSubscription
>
> 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
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
