[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sipping] document paths in sipping-config-framework-07
I haven't seen any comment on this issue yet. It would be nice if
someone could at explain why it should be the way it is in the draft.
There might be some good reason but I can't see what it might be.
I think the RFC should be as clear and logical as possible and I think
the most logical way would be to use the same paths in the ua-profile
subscriptions as in the XCAP paths.
/Dag
>-----Original Message-----
>From: Dean Willis [mailto:dean.willis at softarmor.com]
>Sent: den 26 september 2005 22:55
>To: Zisimopoulos, Haris, VF-Group; dan.ietf at SIPez.com
>Cc: sipping; Allison Mankin
>Subject: Re: [Sipping] document paths in sipping-config-framework-07
>
>
>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
>
>
>
>On Sep 20, 2005, at 11:26 AM, Zisimopoulos, Haris, VF-Group wrote:
>
>> 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: sipping-bounces at ietf.org
>>>> [mailto:sipping-bounces at ietf.org] On Behalf Of Dag Ekengren
>>>> Sent: 15 September 2005 10:31
>>>> To: sipping at ietf.org
>>>> 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 sip-implementors at cs.columbia.edu for questions on current
>>>> sip Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
>> Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
>Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP