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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf