Subject: [Sipping] XCAP in sipping-config-framework-07

From: Goix Walter <[email-masked]>
Date: Fri, 30 Sep 2005 15:55:47 +0200

All,

it is still unclear to me what is the exact relationship between the config-framework and XCAP, and in particular whether/how it can be used *without* XCAP, for other types of content. I'm thinking in particular of the "application" profile-type, and the 'app-id' parameter now called 'auid', which sounds very XCAP-like.

Is it now a MUST to use the "application" profile-type with XCAP, and if not, how could that profile-type be used for content which is not XCAP-related?
XCAP is mentioned many times in the document but there is no clear statement about "When used with XCAP..." rather than "When used independently from XCAP..." (or similar).

Whatever the answer, it may need to be clarified in the text.

Thanks for clarifications

Regards,
Walter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: lunedì 26 settembre 2005 22.55
To: Zisimopoulos, Haris, VF-Group; [email-masked]
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: [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
>
>

_______________________________________________
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

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

_______________________________________________
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