Subject: RE: [Simple] Re: XCAP Directory: Large response ?

From: [email-masked]
Date: Mon, 5 Jul 2004 12:38:02 +0300

I wonder if you can use the following event filtering draft with HTTP GET?

http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-01.txt (currently in WGLC)

At least the <what> part could be useful.

/Hisham

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Miguel Garcia
> Sent: 05.July.2004 10:43
> To: Ted Hardie
> Cc: Jonathan Rosenberg; [email-masked]
> Subject: Re: [Simple] Re: XCAP Directory: Large response ?
> 
> 
> I think the discussion is becoming clearer now. For sure an 
> XCAP client 
> will have knowledge of the schema is trying to 
> download/manipulate, so 
> in most circumstances it can just request to download a few elements 
> (e.g., the "good friends" list).
> 
> The problems is when I get my brand new mobile device, and I 
> want to add 
> a new buddy to my list. First I need to download my complete presence 
> list. If that list is huge (well, imagine my companies 
> employees list), 
> then I may flood my terminal (or even the access network).
> 
> The Range header in HTTP does not seem to be quite useful, 
> since it will 
> truncate the XML document. Then the XCAP client cannot 
> validate it, it 
> can either request the rest of the document or abort the operation.
> 
> The position() XPath operator seems to fulfill the 
> requirements. I can 
> request entries 1 to 50 to avoid flooding my terminal. Since the XCAP 
> server will return a valid XML document, it can be displayed to the 
> user, and do some manipulation. Then the XCAP client can 
> request entries 
> 51 to 100, etc.
> 
> Yes, we don't know how many bytes will be sent to the 
> terminal in each 
> of the pages, but I don't think the exact number of bytes is so 
> important, what is important is the number of entries in a list.
> 
> - Miguel
> 
> Ted Hardie wrote:
> 
> > At 6:00 AM -0400 7/2/04, Jonathan Rosenberg wrote:
> > 
> >>
> >> I would propose that we not put this functionality in xcap 
> itself, but 
> >> use the existing HTTP mechanisms. I will note that these 
> mechanisms 
> >> are *byte* oriented, and not XML oriented. Thus, you may cut an 
> >> element off in the middle by asking for the first 50 
> bytes. However, 
> >> if your main concern is bandwidth or latency, then bytes 
> are much more 
> >> significant of a measure than elements. If I say, "give me 30 
> >> elements", that could be 30 bytes or 30MB, depennding on 
> the amount of 
> >> data in each element.
> > 
> > 
> > I'd like to strongly support this view.  XCAP is currently 
> a profile of
> > HTTP, and re-using HTTP methods makes a great deal of sense here.
> > Attempting to extend XCAP to include mechanisms that are not part
> > of the core of HTTP will require either extending HTTP (hard)
> > or diverging from HTTP (problematic for code re-use, which has
> > been a key factor before).
> > 
> > I'd also like to point out that the problem (unexpectedly 
> large responses)
> > may be less likely than originally supposed.  An XCAP 
> client will have
> > to have some knowledge of the schema with which it is interacting
> > in order to get the base advantage of XCAP over HTTP.  That is, it
> > will have to know the break points between things like the whole
> > buddy list, the list of "friends", the subset of "friends" who are
> > "good friends", and a possibly overlapping set of "work colleagues".
> > While it would not be formally part of the schema, it would not be
> > hard to store the number of elements last known for each of the
> > break points in the hierarchy; indeed, the previous discussion of
> > positional insertions seemed to presume this was stored.   Even
> > without positional insertions, this is useful information that it is
> > relatively easy to store and maintain.  As Jonathan points out,
> > it still won't map perfection to bytes, since elements may be of
> > different sizes, but it will help the client understand the likely
> > size of a request.
> > 
> >         regards,
> >                 Ted Hardie
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 05 Jul 2004 12:50:07 +0300

I am writing a set of comments to the filter format, but when I read the 
document I thought it was only applicable to SIP events. At least the 
Abstract and the Introduction consider only the case where the filter 
applies to SIP Notifications.

However, in this thread, we were discussing XCAP documents that you 
retrieve with an HTTP GET.

Are you suggesting that Filter Criteria documents can be applied to 
XCAP? Is this discussed somewhere?

- Miguel