Subject: RE: [Sipping] document paths in sipping-config-framework-07

From: "Zisimopoulos, Haris, VF-Group" <[email-masked]>
Date: Tue, 20 Sep 2005 17:26:35 +0100

I agree this was my point. So should the assumption described in this
email be considered as correct and the appropriate changes will be done
in the next version of the sipping-config-framework-07 ?

Best regards,
Haris

>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Dag Ekengren
>>Sent: 15 September 2005 10:31
>>To: [email-masked]
>>Subject: [Sipping] document paths in sipping-config-framework-07
>>
>>Hello,
>>
>>This comment is related to the comment the 13th by Haris Zisimopoulos.
>>
>>In sipping-config-framework-07 the section "8.6  Usage of 
>>XCAP with the Profile Package" describes how a document path 
>>is constructed when a client wants to subscribe to a document:
>>
>>For XCAP the relative document path is constructed using the following
>>steps:
>>
>>   1.  Its first path segment is either "global", specifying global
>>       data, or "user", specifying user data for the user in 
>>the request
>>       URI.
>>   2.  If the prior path segment is "user", the next path segment
>>       identifies the the user's home directory.  That is the 
>>next path
>>       segment is the user's directory name.  The user's 
>>directory name
>>       is appended onto the "document" path with the "/" 
>>separator.  If
>>       the prior path segment is "global" nothing is appended to the
>>       document path for this step.
>>   3.  When the "profile-type" is "application", the next path segment
>>       to append (i.e. after "global" or the user's home directory
>>       segment) MAY indicate the XCAP Application Unique ID (AUID) if
>>       the user agent wishes to subscribe to a specific application
>>       profile.
>>   4.  If the AUID was added to the document path in the prior step,
>>       additional path segments may be added according to the specific
>>       schema of the profile and the query mechanism provided in
>>       [I-D.ietf-simple-xcap].
>>
>>
>>For example, if I want to subscribe to a user's document for an
>>application:
>>
>>User: John
>>AUID: myapp
>>Document name: groups.xml
>>
>>then the event header in the subscribe request will look like this:
>>
>>Event: ua-profile; profile-type=application; 
>>document="user/myapp/john/group.xml"
>>
>>The full path to the XCAP server looks like this:
>>http://xcap.example.com/services/myapp/users/john/group.xml
>>
>>So "user/myapp/john" in the subscription request is 
>>interpreted as "myapp/users/john". This is what I find confusing.
>>
>>In my opinion, the path in the document parameter should be 
>>similar to the URL on the XCAP server:
>>
>>Event: ua-profile; profile-type=application; 
>>document="myapp/users/john /group.xml"
>>
>>Best Regards,
>>Dag
>>
>>
>>
>>
>>_______________________________________________
>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>This list is for NEW development of the application of SIP 
>>Use [email-masked] for questions on current 
>>sip Use [email-masked] for new developments of core SIP
>>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dean Willis <[email-masked]>
Date: Mon, 26 Sep 2005 15:55:03 -0500

This draft is currently in AD Review preparatory to being sent up for  
IETF Last Call.

If we need to change it to resolve this issue, we need to get that  
change agreed and made ASAP, and we need to let the AD know to "pull  
back" the -07 draft.

Do we have a consensus that a change here is required?

--
Dean

---

From: Dan Petrie <[email-masked]>
Date: Fri, 30 Sep 2005 09:58:20 -0700 (PDT)

Ok so I some how missed that fact that applications
are higher in the XCAP heirarchy than users (perhaps
it was my dyslexia ;-)  I do think that the
config-framework document parameter and the
XCAP path should be the same.

Now what I do not understand is how a XCAP client is 
expected to discover what applications exist.  Given 
a path heirarchy like the following where applications
are above users, how can I get all of john's 
stuff or discover what applications he uses?

I would like to be able to subscribe to all of john's
stuff using the document parameter:

document="users/john"

With the application name higher in the heirarchy,
I need to know what every application name is
and I have to subscribe to each of them
individually.

It seems to me that the XCAP path heirarch should be 
changed so that users are higher in the path.   I can 
not think of any application that would want to get
the XCAP content for all users of a specific 
application, but I can think of many applications
where it is desireable to get all of a specific
user's content.

Cheers,
Dan

--- Dean Willis <[email-masked]> wrote:

> > email be considered as correct and the appropriate
> changes will be  
> > done
> >>> This comment is related to the comment the 13th
> by Haris  
> >>> Zisimopoulos.
> >>>
> >>> For XCAP the relative document path is
> constructed using the  
> >>> following
> >>> steps:
> >>>
> >>>   3.  When the "profile-type" is "application",
> the next path  
> >>> segment
> >>>       additional path segments may be added
> according to the  
> >>> specific
> >>> Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping
> > Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping