[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] document paths in sipping-config-framework-07
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?
http://xcap.example.com/services/myapp/users/john/group.xml
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 <dean.willis at softarmor.com> wrote:
>
> 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