A few issues bother me with the present draft. I'm not on the ietf
list, but saw this on the wg-dav list.
Section 5.1. Application Unique ID (AUID)
If we assume that an application is a program (or collection of
programs working together towards a common goal) then this section
assumes that keys based on domain names will be unique in perpetuity
(though section 15 allows an application to be released commercially
if the IETF provides an RFC for the application). This only becomes
a problem for applications that have been abandoned by their
vendors, whose vendors have changed names, or those applications
which are unable to push an RFC through the IETF.
A better solution might be using OIDs similar to LDAP attributes.
These do not depend on the name of the organization. Neither will
a second organization coming after the first and selecting the same
name have to be aware of the first organization's history.
If an application is not a program, but a set of capabilities that
might be implemented by a wide range of programs (colloquially
called applications, each of which might be composed of several
programs working together), then the section can probably stand as
it is.
In either case, the use of the word application needs to be
clarified. The definition in Section 4 could cover either
assumption. E.g., to pick on a product I work with, Sendmail's SAMS
product (Sendmail MTA, imap/pop server, lmtp daemon, etc.) could be
considered a collection of software components within a network
whose operation could [conceivably, if implemented to do so,] depend
on data managed and stored on an XCAP server, but the product does
not fit the spirit of the application in the second sense of the
application being a set of capabilities that might be implemented by
a wide range of programs. It fits better the first sense of the
application being a program, yet it also fits the definition in
Section 4.
Section 5.3. Data Validation
Paragraph 6 should read (changed lines indicated by > ):
Another important data constraint is referential integrity.
Referential integrity is important when the name or value of an
element or attribute is used as a key to select another element or
attribute. An application usage MAY specify referential integrity
constraints. However, XCAP servers are not a replacement for
Relational Database Management Systems (RDBMS), and therefore clients
MUST NOT depend on servers to maintain referential integrity. XCAP
clients are responsible for making all of the appropriate changes to
documents in order to maintain referential integrity.
This is the same meaning, but by saying MUST NOT, clients who do
depend on the server for referential integrity will be considered
non-compliant whereas without those words, some could argue that
non-dependence is not a requirement as specified by section 3.
Similar cases could probably be made for other sections in the
draft.
Section 7.10. Fetch Namespace Bindings
A slight grammatical correction:
If a client wishes to insert an element or attribute into a document,
and that element or attribute is part of a namespace declared
elsewhere in the document, the client will need to know the namespace
The following discussion outlines why I feel the handling of
namespaces as defined in this draft will surprise people who are
used to XML namespaces.
Namespace prefixes are shorthand for the full namespace
specifications. The handling of namespace prefixes in this draft
seems to be out of step with the expectations that someone
conversant in XML would have.
For example, if I have the following snippet of XML,
<root-element xmlns:ns1="some:url" xmlns:ns2="some:url">
<ns1:sub-element/>
<ns2:sub-element/>
</root-element>
then the XPath expression "//ns1:sub-element" should select two
elements. The XPath expression "//ns2:sub-element" should select
the same two elements.
From http://www.w3.org/TR/REC-xml-names :
Section 1. Motivation and Summary
The prefix, which is mapped to a URI reference, selects a
namespace. The combination of the universally managed URI namespace
and the document's own namespace produces identifiers that are
universally unique.
Section 3. Qualified Names
Note that the prefix functions _only_ as a placeholder for a
namespace name. Applications should use the namespace name, not the
prefix, in constructing names whose scope extends beyond the
containing document.
(end of quoting from REC-xml-names)
The two sections use two different names for the same things:
namespace name and URI reference. This is evident by looking
through section 2.
To comply with the XML Namespace spec, The server MUST be able to
translate the namespace prefixes specified by a client PUT or DELETE
request to the namespace names (or URI references) used internally
in the server's document that is being modified.
--
James Smith <JGSmith(_at_)TAMU(_dot_)Edu>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf