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@xxxxxxxx>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf