Re: Fwd: Last Call: 'The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)' to Proposed Standard (draft-ietf-simple-xcap)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

below are some (late) last-call comments.

Best regards, Julian

--

1) XML Schema

It seems that the specification normatively requires servers to implement XML Schema. I'm not sure that this is a good idea, I can easily imagine scenarios where the server has a built-in hardwired schema, or may want to use a different schema language.

If this is an allowed scenario, it's not obvious from the text.

2) Etags (Section 8.5)

The specification requires the ETag to be the same for each resource in an XCAP document. This seems to be overly restrictive, and may be hard to implement for stores that can manipulate XML fragments on a fine-grained level.

From a client's point of view, the only important thing should be that ETags work as defined by RFC2616. It seems to be better to mention the "same Etag for every resource" approach simply as one potential implementation strategy.

3) RFC2818 (Section 8)

There's a normative reference to RFC2818, which is informational (same problem as in CalDav). Probably, other normative references need to be rechecked as well.

4) UTF-8 (Section 8.2.2)

The specification requires content to be exchanged using UTF-8. It would be nice if there'd be a rational mentioned for that (should there be one :-)).

5) Content rewriting (Section 8.2)

As we're talking about an XML store, the section about PUT probably should mention that clients can not rely on the content being available after GET is the same (octet-by-octet) as that was PUT (due to various aspects of XML normalization). Note that the behaviour specified here is incompatible to the one defined in CalDAV (draft 12, Section 5.3.4), thus a given HTTP URL may never point both to a CalDAV calendar resource and a node in an XCAP document at the same time. In this particular case, this may be OK, but I think this shows that we really need to be careful when introducing requirements that aren't defined in RFC2616.

6) AUIDs

I didn't have time to review this in depth, but I hope that the benefits of this mechanism outweigh the additional complexity (that is, (1) new IANA registry: wouldn't be URIs for this sufficient???, (2) why not just use MIME types instead). See also comments from Roy Fielding in <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0143.html>.


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]