Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - Resource List Subscription

From: "Vavilapalli Srikanth-A19563" <[email-masked]>
Date: Fri, 9 Apr 2010 15:07:46 +0800

Forwarding to SIMPLE mailing list... 

-----Original Message-----
From: Pandurangan R S [mailto:[email-masked]] 
Sent: Friday, April 09, 2010 12:07 PM
To: Vavilapalli Srikanth-A19563
Cc: [email-masked]
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
<[email-masked]> 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
> [email-masked]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

---

From: "Vavilapalli Srikanth-A19563" <[email-masked]>
Date: Fri, 9 Apr 2010 15:21:25 +0800

-----Original Message-----
From: Pandurangan R S [mailto:[email-masked]]
Sent: Friday, April 09, 2010 12:07 PM
To: Vavilapalli Srikanth-A19563
Cc: [email-masked]
Subject: Re: [Sip-implementors] Question on RFC 4662 - Resource List
Subscription

RFC 4662 states

---

From: "Vavilapalli Srikanth-A19563" <[email-masked]>
Date: Fri, 9 Apr 2010 16:50:33 +0800

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:[email-masked]"
         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:[email-masked]"">
       <name>Bob Smith</name>
       <instance id="juwigmtboe" state="active"
                 cid="[email-masked]"/>
     </resource>
     <resource uri="sip:[email-masked]">
       <name>Dave Jones</name>
       <instance id="hqzsuxtfyq" state="active"
                 cid="[email-masked]"/>
     </resource>
     <resource uri="sip:[email-masked]">
       <name>Ed at NET</name>
     </resource>
     <resource uri="sip:[email-masked]">
       <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 "[email-masked]"
contains members as 
sip:[email-masked], 
sip:[email-masked], 
sip:[email-masked] and 
sip:[email-masked]

Not sure why RFC mandates/recommends to keep the entire buddy list info
in the first NOTIFY.. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Vavilapalli Srikanth-A19563
Sent: Friday, April 09, 2010 12:38 PM
To: Pandurangan R S; [email-masked]
Cc: [email-masked]
Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 -
ResourceList Subscription

-----Original Message-----
From: Pandurangan R S [mailto:[email-masked]]
Sent: Friday, April 09, 2010 12:07 PM
To: Vavilapalli Srikanth-A19563
Cc: [email-masked]
Subject: Re: [Sip-implementors] Question on RFC 4662 - Resource List
Subscription

RFC 4662 states

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 9 Apr 2010 11:38:09 +0200

2010/4/9 Avasarala Ranjit-A20990 <[email-masked]>:
>
> It could be that they did not anticipate the buddy list to very large
> one.

Or it would be that the whole mechanism to mantain a buddylist with
SIMPLE/XCAP is a pain, by handling two different protocols (SIP and
HTTP) and a complex relationship between them (even more on the
presence and XCAP server, as the communication betweeen them is mostly
"undefined").

So, it's supposed that HTTP/XCAP is used to allow SIP UDP as HTTP
allows large documents, but later RFC 4662 itself makes mandatory to
notify the entire (large) document the first time. Annoying.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Apr 2010 10:42:35 -0400

> It could be that they did not anticipate the buddy list to very large

Or it could be that they expected that the implementors would support 
TCP, as 3261 requires them to do.

	Thanks,
	Paul

> Ranjit
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> Vavilapalli Srikanth-A19563
> Sent: Friday, April 09, 2010 2:21 PM
> Subject: Re: [Sip-implementors] [Simple] Question on RFC 4662 -
> ResourceListSubscription
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 9 Apr 2010 17:09:22 +0200

> TCP, as 3261 requires them to do.

Then, the pain of HTTP/XCAP wouldn't be required, just a new SIP
method to store info in the presence server permanently.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 9 Apr 2010 11:19:05 -0500

<as SIMPLE-chair>

The decision to use XCAP rather than SIP for provisioning this sort of thing reflects work group consensus after a lot of discussion. People are certainly welcome to propose new work in SIMPLE, DISPATCH, or elsewhere. But unless you plan to make a concrete proposal for new work, please don't use the SIMPLE list to rehash old points of consensus.

Thanks!

Ben.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 9 Apr 2010 19:33:24 +0200

> The decision to use XCAP rather than SIP for provisioning this sort of thing reflects work group consensus after a lot of discussion. People are certainly welcome to propose new work in SIMPLE, DIS…

SIP is (or should be) IMHO enough powerful to carry information about
buddies and permissions without the need of using other protocols
which makes the whole specification complex. For sure I'll propose
something very different, just based on SIP protocol, in a future :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 9 Apr 2010 10:45:39 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Vavilapalli Srikanth-A19563 [[email-masked]]

I suspect it is so that the subscriber will know what resources the list contains.  If information about the resources could be sent completely incrementally, then the subscriber might have to wait a long time before it even knew the number of resources in the list.

Dale

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 9 Apr 2010 16:53:35 +0800

Regards
Ranjit

-----Original Message-----
From: Pandurangan R S [mailto:[email-masked]]
Sent: Friday, April 09, 2010 12:07 PM
To: Vavilapalli Srikanth-A19563
Cc: [email-masked]
Subject: Re: [Sip-implementors] Question on RFC 4662 - Resource List
Subscription

RFC 4662 states