Subject: [Simple] updated XCAP draft

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Oct 2006 13:31:41 -0400

I've submitted an update to XCAP. THe changes reflect comments from IESG 
during last call, in addition to a few bugs reported on the list and 
privately since -11. Until the update appears in the archives, you can 
pick it up at:

http://www.jdrosen.net/papers/draft-ietf-simple-xcap-12.txt

Here are the changes:

* clarified the distinction between 'default document namespace',
   which is the default namespace used in evaluation of XCAP URIs, and
   'default namespace', which is the standard XML term for defaults
   within XML documents. Using those two different terms consistently
   in the specification

* added the following warning where the structure of the XCAP URI is
   discussed:

Implementors making use of HTTP servlets should be aware that XCAP
may require them to get authorization from the server administrator to
place resources within this specific subset of the URI
namespace.

* Clarified handling of redundant namespace declarations in Section
   8.2.3:

<t> If the element being inserted (or any of its children) contain
namespace declarations, those declarations are retained when the
element is inserted, even if those same declarations exist in a parent
element after insertion. The XCAP server MUST NOT remove redundant namespace
declarations or otherwise change the namespace declarations that were
present in the element being inserted.
</t>

and within 8.2.4:

<t>
As with creation, replacement of an element does not result in the
changing or elimination of namespace declarations within the newly
modified element.
</t>

* clarified that namespace bindings are not added in a GET
   response. The following was added in section 8.3:

The server MUST NOT add namespace bindings
representing namespaces used by the element or its children, but
declared in ancestor elements; the client will either know these bindings
already (since it has a cached copy of the whole document), or it can
learn them by explicitly querying for the bindings.

* clarified in section 8.2.5:

If a schema allows for
elements or attributes from other namespaces, and the new document
contains elements or attributes from an unknown namespace, the server
MUST allow the change. In other words, it is not necessary for an XCAP
server to understand the namespaces and corresponding schemas for
elements and attributes within a document, as long as the schema
itself allows for such elements or attributes to be included. Of
course, such unknown namespaces would not be advertised by the server
in its XCAP capabilities document <xref target="sec:xcap-caps"/>.
</t>

* also clarified in section 8.25 the handling of unknown elements from
   a known namespace:

<t>
If the final document contains elements or attributes from a namespace 
that the
server does understand (and has consequently advertised in its XCAP
capabilities document), but the server does not have the schema for
that particular element or attribute, the server MUST reject the request 
with a 409
response. That response SHOULD
contain a detailed conflict report containing the
&lt;schema-validation-error&gt; element.
</t>

* Clarified in Section 12 what it means to support a namespace:

To 'support' a namespace, the
server must have the schemas for all elements within that namespace,
and be able to validate them if they appear within documents.

* clarified in 8.2.7 that a successful PUT response MUST include an
   entity tag. This was already stated in section 8.5 but is repeated
   here as part of PUT processing.

* clarified in 8.3 that a successful GET has to include an etag.

* clarified in 8.4 that if the document remains after DELETE, the 200
   OK response must include an etag

* in section 8.5 on managing etags, clarified that there is basically
   one etag for the whole document. This was kind of opaque
   before. First paragraph now reads:

<t>
An XCAP server MUST maintain entity tags for all resources that it
maintains. This specification introduces the additional constraint
that when one resource within a document (including the document
itself) changes, that resource is assigned a new etag, and all other
resources within that document MUST be assigned the same etag
value. Effectively, there is a single etag for the entire document. An
XCAP server MUST include the Etag header field in all 200 or 201
responses to PUT, GET, and DELETE, assuming the document itself still
exists after the operation. In the case of a DELETE, the entity tag
refers to the value of the entity tag for the document after the
deletion of the element or attribute.
</t>

* removed text that allowed weak entity tags. Spec merely says that
   xcap doesn't introduce new requirements on strength of entity
   tags. Allowance for weak etags was added in -03 but I found no
   record of discussion for this change and I cannot recall why I put
   it in. Weak entity tags are strongly discouraged these days, so the
   text allowing them was pulled.

* clarified in 7.11 that it is not possible to insert an element or
   attribute condition on the operation being an INSERT and not a
   replacement:

One way to think of this is that,
logically speaking, on receipt of the PUT request, the XCAP server
instantiates the etag for the resource referenced by the request, and
then applies the processing of the request. Because of this behavior,
it is not possible to perform a conditional insert on an attribute or
element conditioned on the operation being an insertion and not a
replacement. In other words, a conditional PUT of an element or
attribute with an If-None-Match: * will always fail.  </t>

* Section 14, security considerations, now requires client TLS
   implementation (new content is the last sentence):

<t>
Frequently, the data manipulated by XCAP contains sensitive
information. To avoid eavesdroppers from seeing this information, it is
RECOMMENDED that an admistrator hand out an https URI as the XCAP root
URI. This will result in TLS-encrypted communications between
the client and server, preventing any eavesdropping. Clients MUST
implement TLS, assuring that such URIs will be usable by the client.

</t>

This was implied but instated previously. Similarly, clients MUST
implement digest and servers MUST NOT use basic without TLS (new
content is the last two sentences):

<t>
Client and server authentication are also important. A client needs to
be sure it is talking to the server it believes it is
contacting. Otherwise, it may be given false information, which can
lead to denial of service attacks against a client. To prevent this, a
client SHOULD attempt to <xref target="RFC2817">upgrade</xref> any
connections to TLS. Similarly, authorization of read and write
operations against the data is important, and this requires client
authentication. As a result, a server SHOULD challenge a client using
<xref target="RFC2617">HTTP Digest</xref> to establish its identity,
and this SHOULD be done over a TLS connection. Clients MUST implement
digest authentication, assuring interoperability with servers which
challenge the client. Servers MUST NOT perform basic authentication
without a TLS connection to the client.
</t>

* Labeled the examples in the example section (though I cannot figure
   out how to fix the odd figure numbering that xml2rfc does; rfc-ed
   will need to repair that)

* clarified the meaning of application in the introduction:

<t> Each application (where an application refers to a use case that
implies a collection of data and associated semantics) that makes use

* reworded discussion on referential integrity, which now reads:

<t>
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. </t>

* mentioned in Section 8.3 (GET processing)

<t>
Note that the GET of a resource that was just PUT might not be
octet-for-octet equivalent to what was PUT, due to XML normalization
and equivalency rules.
</t>

* fixed grammar bug. Previously:

  attr-test              = ( "@" att-name "=" <"> att-value <"> ) /
                             ( "@" att-name "=" <'> att-value <'> )
    by-attr                = NameorAny "[" attr-test "]"
    by-pos-attr            = NameorAny "[" position "]" "[" attr-test "]"
    NameorAny              = QName / "*"   ; QName from XML Namespaces
    att-name               = QName
    att-value              = AttValue      ; from XML specification

but AttValue is already defined with the quotes (single and double) so
this is wrong. Grammar is now corrected to:

attr-test              = "@" att-name "=" att-value
by-attr                = NameorAny "[" attr-test "]"
by-pos-attr            = NameorAny "[" position "]" "[" attr-test "]"
NameorAny              = QName / "*"   ; QName from XML Namespaces
att-name               = QName
att-value              = AttValue      ; from XML specification

* clarified the following nonsensical text in 8.2.3:

Not any <bar> element may precede one or multiple <foo> elements.

to say:

Based on this schema, the document contains some number of &lt;foo&gt;
elements followed by some number of &lt;bar&gt; elements.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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