Subject: draft-ietf-simple-xcap-11

From: James G Smith <[email-masked]>
Date: Tue, 13 Jun 2006 15:03:52 -0500

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 seleubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

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 <[email-masked]>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

ct
 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 <[email-masked]>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf