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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf