Subject: [Simple] Comments on xcap drafts

From: Ben Campbell <[email-masked]>
Date: 28 May 2003 20:10:37 -0500

I like the overall approach a lot. Here are my comments, the vast
majority of which are nits.

Introduction:

(nit) You conflate server storage of presence lists with list
subscriptions. It may be useful to store such lists on servers simply to
facilitate list mobility, even without list subscriptions. Conversely,
although we have not defined it, there may be some use for ad-hoc list
subscriptions, where the contents of the list are _not_ stored on a
server, but rather carried in the subscription request.

I think the xcap URIs actually fit the definition for URLs. Should we
not simply call them URLs?

Are global and user trees normative, or simply examples?

6.4 Do we really want clients doing this rather than using the event
package? If so, should there be guidelines on minimum poling intervals?

6.6 It seems like MUST be text/plain is a little strong. Cannot an
application define elements where other types would be more appropriate?

6.8 If I get an XML document containing only one element, is that by
nature guaranteed to be schema compliant?

7: Use of 404 for service not found and user not found does not give
much granularity.

draft-rosenberg-simple-xcap-list-usage-00.txt:

Introduction:

(nit) Language of the form "users subscribe to their presence list"
implies a single list, where a user may indeed have many lists.

I agree that policy specification should be kept separate.

5: It seems like there are some uniqueness requirements for list URIs
that should be addressed here.

8. The security policies here do not seem to allow the concept of shared
lists. We may eventually want ACLs for a list. I can accept that this
might currently be out of scope, but it may be useful in a future
extension.

draft-rosenberg-simple-xcap-package-00.txt:

(nit) I would s/package/event-package in the document title. I did not
realize this was a sip events package until I read the abstract.

2.2 I would rather the r-uri to indicate the doc-component being
subscribed to, not the user. What about global data not associated with
a user? The semantic should be I subscribe to the piece of information,
then the server decides if the user (me) is authorized. The fact the
data belongs to my user tree does not change that--it just indicates a
high likelyhood that I am authorized. As written, the semantic seems
more like I am subscribing to the user, with a filter to determine the
doc-component.

2.4 The motivation for choosing high default expiration times ignores
the fault-recovery aspect of soft state. Large expiration times increase
the time before a client will discover a server failure

2.5. It seems inconsistent to have only the version returned in the
first NOTIFY, but the actual changes returned in subsequent ones. It
might be worthwile to at least allow a mode where only the new version
gets returned in a NOTIFY. This allows a client to invalidate its cache,
and only retrieve the new data when it needs it.

4. Are their security considerations around knowing who changed
something? For example, if A subscribes to a doc-component, and B
changes it, shoud A know B was the culprit? This might indicate a need
for signing changes.

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