[Simple] Updated XCAP spec now available and ready for wglc!

[Jonathan Rosenberg <jdrosen at dynamicsoft.com>]

Folks,

I've just submitted an updated to the XCAP core specification. Until it 
appears in the archives, you can pick up a copy at:

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

This is a fairly major update, mostly in terms of document organization 
and clarity, which I think is vastly improved.

Here are the resolutions to the various open issues, which are 
incorporated into this version:

ISSUE 1: schema awareness - when it is needed?
  Only for validation

ISSUE 2: positional insertions?
  They have been added

ISSUE 3: PUT vs. POST
  Continue to use PUT.
  Server never modifies the document submitted via PUT. Rather, the 
client picks a URI, and if its not unique, the server rejects the 
request and suggests unique alternatives in the body of the error response.

ISSUE 4: Document/element separators
  Using double tilde (~~)

ISSUE 5: Multiple Insertions
  deferred to another document, to be debated separately from core xcap

ISSUE 6: Selection by text element value
  decided not to include this feature

ISSUE 7: Unique steps at each hop
  Uniqueness is required at each hop

ISSUE 8: Etag scopes
  Etags are scoped to a document

ISSUE 9a: Supported namespace discovery
  Added a capability application usage, in which the supported 
namespaces of the server can be listed

ISSUE 9b: Etags useless for insert
  Documented this problem, suggest workarounds


As such, there are no open issues that I am aware of. As a result, I 
believe this document is done, and now ready for working group last call 
(yay!).

There are two TODOs in the document, which are questions I need 
assistance in answering. Once answered, text can be incorporated into 
the document.

There are many changes in addition to the above issue resolutions. Many 
are clarifications, fixes, and other things discussed on the list and at 
the interim. The following is a summary of the main ones:

* To fetch a document, -02 recommended using the If-Match header field to
do a conditional get. This should have been If-None-Match, and has been
corrected in this revision.

* Added definitions section

* Terminology cleanup. A key term here is "XCAP resource" which refers
to a document, element, or attribute which follows XCAP naming and
data validation constraints.

* Beefed up the section on what an application usage has to specify
when it defines its data validation rules. The section discusses XML
schema, uniqueness constraints, URI constraints and referential
integrity. XCAP now
requires each application usage to explicitly call out uniqueness
constraints, even if those constraints are also specified in the
schema using the <unique> tag.

* Explicitly say that XCAP servers are not responsible for referential
integrity. This is the responsibility of the client. XCAP is not an
RDBMS!

* renamed "Data Interdependencies" to "Resource
Interdependencies". This is commensurate with the change that the
server doesnt update documents PUT to the server (XCAP issue
3). Indeed, this aspect
of the application usage is talking about something quite different
now. When a client PUTs a resource, the server changes the state of OTHER
resources. Most interdependencies are expressed in schema; a PUT to an
element changes the contents of all of the child elements and
attributes. However, in some cases, there are inter-dependencies
across docs, and the app usage needs to specify that. We have two
examples so far - the index document created by the server in the list
usage, and Miguel's directory usage.

* terminology: XCAP User ID (XUI). This is the "username" present in
the xcap URI. It need not be the actual "username".

* removed "mandatory-ns", which was our approach for allowing the
client to mandate that a server understand a particular namespace
before processing a document. Instead, there is an application usage
that contains a document that lists the server's capabilities, which
includes namespaces, application usages and xcap extensions. [ISSUE 9]

* clarified that a server can have multiple root services URIs, and that
there is never interactions or information carryover across root services

* clarified that the xcap root services URI (now called Xcap root URI)
is a valid HTTP URL but doesnt actually refer to any existing resource

* added usage of the ~~ path segment to separate the document and node
selectors

* added rules for escape coding. Note that the left bracket, right
bracket and double quote need to be escaped. Also, since XML elements,
attributes, and attribute values can contain unicode characters, any
unicode characters outside of US-ASCII need to be escape coded. I
lifted some text from rfc2396bis that documents how this escape coding
is done.

* comparison rules for the element and attribute names in the node
selector against those in the document have been aligned with the
XPath rules. In particular, the namespace bindings used to resolve
namespace prefixes in the node selector are taken from those in scope
for the context element. Also, if the element name in the node
selector has no prefix, its namespace URI is null, *NOT* the default
namespace of the context element. This is accoring to XPath. However,
I can't see how this can work. Need to follow up on that with an Xpath
expert.

* The detailed conflict report document has two new errors -
uniqueness failure and constraint-failure. no-xml-att-value has been
renamed to not-xml-att-value for consistency. The no-element was
removed; no-parent is used for all of these cases. cannot-insert now
specifically refers to PUT operations that would not be
idempotent. The uri-exists error has been generalized to
uniqueness-failure, covering other uniqueness constraints that an
application usage might impose. The schema uses substitution groups
for extensibility. The spec says that XCAP extensions can add new
elements.

* added an application usage that contains capabilities of the server
- supported auid, supported namespaces, and supported extensions. A
single instance of this document is in the global directory with the
name "index"

* beefed up the server processing of PUT

* clearly indicate that schema awareness is not needed to insert, only
to validate [ISSUE 1]

* added positional inserts [ISSUE 2]. Give guidance to clients on how
to use them.

* removed whole idea of server filling in URI. That is now handled by
having the server reject non-unique URI [ISSUE 3]

* Added the "path separator" which is a path segment between document
selectors and node selectors, with value of double tilde [ISSUE 4]

* The section on construction of the http URI makes it very clear that
each step in the selection process when processing the node selector
MUST result in a single element [ISSUE 7]

* Etag scope is document wide still, as it was in -02. The wording was
cleaned up on it [ISSUE 8]

* Changed the mime type of application/xml-fragment-body to
application/xcap-el+xml and application/xml-attribute-value to
application/xcap-att+xml, per discussions during ietf 59

* clarified that escape encoding of xcap components only applies when
they appear in a URI, so body components will not be escape encoded

* Clarified that, in the case where the client does not do a
positional insertion, the element gets inserted at the end

* Changed read/update/write transaction section to "Conditional
Operations", since etags doesnt give "transactional" behavior in the
true definition. This section has been cleaned up a lot. It also
includes an example of using the If-None-Match:* to do a forced
creation.

* Documented that conditional operations are useless for creation
operations, and recommend that if conditioning is needed, the client
instead modify the parent resource. [ISSUE 9]

* Updated IANA registry to include namespace and schema registrations
for xcap-caps document. Also, fixed up schema registrations, which
apparently need to include a schema URN. I had thought these were
assigned by IANA, and equal to a URL where the schema can be fetched
from, but they are not.

* mention that redirects are applicable here just as for any other
http resources

* added a bunch of text to clarify the "do we need filename extensions
or not" issue. The answer is this: for well known documents, defined
by the naming conventions in the application usage, it will say how
the document is named. In other cases, a document has to be referenced
from a well known place, so it doesnt matter how its named, as long as
you have referential integrity.

* documented idempotency requirements on PUT and DELETE
requests. Describe the known cases for element and attribute
insertions when the request results in a document that meets the data
constraints of the application usage, but is not idempotent.

* added a section on guidelines for application usage design, covering
both schema design and naming convention design

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen at dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple