Subject: [Simple] Comments on draft-ietf-somple-xcap-03

From: [email-masked]
Date: Wed, 28 Jul 2004 11:47:07 +0300

Most of the comments are nits. When fixed, I believe the draft is ready.

Section 1
----------
- 1st para: s/by the end user themselves/by end users themselves
- 2nd para: 2x presence list mentioned. Change to resource list. Also add a reference.
- 2nd para: s/for the list of is to/for the list is to
- 3rd para:  "specified by the SIMPLE working group". I suggest removing reference to the working group, unless you believe it will exist for ever an all readers of the RFC will know about it ;)

Section 2
----------

- 1st para: Change

"The principal task of XCAP is to allow clients to read,
   write, modify, create and delete pieces of that data."

to 

"The principal task of XCAP is to allow clients to read,
   write, modify, create and delete all or pieces of that data."

- 1st para: s/XCAP points a document/XCAP points to a document

Section 5.1
------------

- 1st para: s/name name/name

Section 5.4
------------

- Second para:

"As an example, the RLS services application usage allows an RLS to
   obtain the contents of a resource list when the RLS receives a
   SUBSCRIBE request for a SIP URI identifying an RLS service.  The
   application usage specifies that the list of service definitions is
   present within a specific document with a specific name within the
   global tree.  This allows the RLS to perform a single XCAP request to
   fetch the service definition for the service associated with the SIP
   URI in a SUBSCRIBE request."

I could not understand this paragraph. What is it trying to say? From what I read it is trying to say that a SIP URI can be used to derive the XCAP URI to fetch the document from the XCAP server. Clearly wrong, but that's what I read. Please rephrase this paragraph (I would suggest text if I knew what it is trying to say).

Section 6
----------

- 1st para: s/with a escape coded/with an escape coded
- 1st para: s/It is piece of/It is a piece of

Section 6.3
------------

- I believe it is beneficial for the double forward slash // be available in the BNF. It means all occurrences of the element in the document. For example

"//watcher" means all watcher elements. Therefore not requiring all the elements on the path to the watcher element to be included.

An xcap PUT example would be:

PUT http://xcap.example.com/services/resource-list/users/bill/fr.xml/~~//list[@name"friends"]

If this is adopted, then you need to modify the sentences later in the chapter that discuss context and child elements.

- The node-selector does not contain the leading forward slash "/"? An XCAP URI takes the form

http://xcaproot/document/~~/node-selector

Where are the / before and after ~~ defined. Maybe something in section 6 is needed.

"The URI is constructed by concatenating the
   XCAP root with the document selector with the path separator with a
   escape coded form of the node selector. A forward slash "/" is placed between each concatenation"

- 4th para: s/MUST be escaped coded/MUST be escape coded

- 5th para: s/discussions an examples/discussions and examples

- 8th para: says that an element name can be wildcarded. I believe it is important to add text saying that even when a wildcard is used, the element must still be unique.

- 12 para: It says that "If the result is a no-match, the node selector is invalid". This is incorrect. no-match is not the same an invalid as far as I understood. no-match results in insertions for PUT and 404 for GET ,while invalid results in an error response being returned. If believe this sentence needs to be removed.

- 15th para: There is a TODO that needs to be done or removed.

- Figure 3 appears in this section, but figures 1 and 2 appear no where, nor any figures after figure 3. Either remove the figure name and number here or add figure numbers to all the figures in the document. Note that figure 3 is referenced on page 24.

Section 7
----------

- 5th para: s/will dictate involve a/will dictate a
- 6th para: I suggest changing the sentence "a subsequent DELETE to the same URI should find the resource deleted" to "a subsequent DELETE to the same URI should not find the resource".

Section 7.4
------------

- 2nd para: s/To create this this element/To create this element
- The URI in the PUT example towards the end of the section is truncated

Section 7.5
------------

- Some text on the idempotent requirements would be useful
- Some text on no-match would be useful

Section 7.6
------------

- Some text on no-match would be useful

Section 7.7
------------

- The URI in the PUT example towards the end of the section is truncated

Section 7.8
-------------

- Some text on the idempotent requirements would be useful
- Some text on no-match would be useful

Section 7.9
------------

- Some text on no-match would be useful

Section 7.10
-------------

- last para: s/a when a/when a
- last para: 304 response???

Section 8.2.1
-----------

- 1st para: s/doocuments/documents
- 3rd para: 

"  If the parent URI has a path separator, the document selector is
   extracted, and that document is retrieved.  If the document does not
   exist, the server MUST return a 409 response, and SHOULD include a
   detailed conflict report including the <no-parent> element.  If it
   does exist, the node selector is extracted, and unescaped (recall
   that the node selector is escape coded).  The node selector is
   applied to the document based on the matching operations discussed in
   Section 6.3.  If the result is a no-match or invalid, the server MUST
   return a 409 response, and SHOULD include a detailed conflict report
   including the <no-parent> element."

Is the last sentence correct? I don't think so. A no-match in this case means an insertion. An invalid means that multiple elements where selected. A <no-parent> in the conflict report does that make sense in this case

- 4th para: talks about target selector. What is target selector? It is not defined anywhere. I believe this paragraph can be removed if the correction to the previous paragraph as made as suggested above.

Section 8.2.5
--------------

- 2nd para: "First, the server checks that the final document is compliant to the schema." Does that mean it checks that the document is valid according to the schema? If so, then the text should mention that if the insertion is for a namespace that the server does not understand, the validation cannot be made.

Section 8.5
-----------

- 1st para: There is a TODO. Will we see etags in DELETE responses? I think we should. It does change the document.
- As in the client section, this section should mention when a server generates a 2xx and when it generates a 4xx using If-match and if-not-match headers.

Section 9
----------

The schema validates as does the example ;) (using XMLSpy)

Section 12
-----------

- I have nothing extra to add to this security consideration section, but it just seems a little too small. Perhaps examining scenarios would make it took more like the homework was done.

Regards,
Hisham

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