Document: draft-ietf-simple-xcap-05.txt, draft-ietf-simple-xcap-list-usage-04.txt draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt Review: Spencer Dawkins Date: 1 januari 2005 I reviewed draft-ietf-simple-xcap-05.txt, draft-ietf-simple-xcap-list-usage-04.txt, and draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt for publication as Proposed Standards, as part of IETF Last Call for these documents. I am not, of course, a Genius of XCAP, or of SIMPLE... > From a General-Area perspective, these documents are on the right track for publication as Proposed Standards. I have one comment on draft-ietf-simple-xcap-05.txt that is worth noodling about with the auhor (see Sections 7.5 and 7.10 below), but everything else is just requests for clarification and editorial nits. These drafts will benefit from a proofreading pass, but I didn't focus on this since the RFC Editor now has an actual document editor on staff. Spencer Detailed notes: draft-ietf-simple-xcap-05.txt - Section 1 - I found the second paragraph of the introduction pretty confusing - I can't tell whether "presence authorization policy and presence lists" is one thing or two - they are described as "examples", plural, but only "presence lists" is defined. - Section 2 - RFC 2616 consistently calls the protocol "HTTP/1.1", with a slash - use the same label in this document? - Section 2 - last paragraph - I spent some time wondering "why PUT and not POST?", since POST is much more common in my world. The document answers this question - but not until section 8.1. Maybe worth a sentence here? - Section 4 - the definition for AUID left me wondering "unique within what scope?". And I was totally dazzled by "Although a valid URL, the XCAP Root URL does not correspond to an actual resource". Could you explain this a little? I'm GUESSING that "Although the XCAP Root URL looks like a valid URL, there are no defined operations for this URL", or something. Mumble. Help! - Section 5.2 - s/Another form of constraint are URL constraints/URL constraints are another form of constraint/, or something that matches the numbers. - Section 5.5 - s/need to affect/will affect/ - Section 7 - "the application usage will dictate involve a uniqueness constraint" - couldn't parse well enough to suggest text. - Section 7.5 - I'm not a Genius of XCAP, but have been following the work long enough to have witnessed some discussions about positional updates and deletions. I'm still concerned that the strategy still seems to be "let an operation that violates some constraint succeed and pass back enough information for the client to figure out that a bad thing has happened", and I'm wondering - if the clients have to spend effort looking at XCAP diff documents in responses to figure out if they hit what they were aiming at, even specifying a unique-attribute-value as part of the node selector, why are positional updates and deletions required? (My apologies here - I spent too long as a database admin to be casual about the possibility of overlapping writes and reads that screw up other clients - maybe this isn't a concern for XCAP?) - Section 7.10 - essentially the same concern - I'm not happy about "Fortunately, the client can at least detect, after the insertion is performed, whether or not the document had been modified prior to the insertion" - by getting an XCAP diff document back, and then dithering about what to undo in fixing things, while who-knows-who is reading the modified document with the missing update and doing who-knows-what based on the wrong information. Again, maybe this isn't a concern for XCAP, but XCAP seems pretty general-purpose, and sooner or later, someone will probably care. If nothing else changes, it's at least worth a sentence in Security Considerations. - Section 8.2.6 - I'm really confused by the first paragraph, where "Normally a server will not need to actually do anything to meet this requirement" - and "this requirement" seems to point to a MUST, two sentences earlier. Mumble. - Section 9 - seems to say that using a short max-age for dynamic information that may be outdated is reasonable - wouldn't the suggested alternative, no-cache, be a preferable recommendation in all cases where someone actually cares about whether proxies provide information that's correct from the origin server's viewpoint? ("A little bit outdated" is like "a little bit pregnant" to database admins!) - Section 12 - s/doesnt/doesn't/ draft-ietf-simple-xcap-list-usage-04.txt - Abstract - I was confused by whether the URI represents a resource list service, or a resource list. Are these terms interchangeable? The "resource list service" URI seems to map 1:1 to "the associated group", in the third sentence. - Section 3.1 - I can't find a functional definition for "anchor". Most of the text in the second-to-last paragraph is actually constraints that are repeated in 3.4.4. What does it do? It's only defined as "similar to the element". - Section 3.3 - s/content is for/content are for/ - Section 3.4.6 - s/priveleged/privileged/ more than once in the document, I believe. - Section 4.1 - s/document in present/document is present/ ? but it didn't parse for me. - Section 4.4.7 - second to last paragraph - I'm not sure what "The server MUST, at all times, be capable of processing requests against the global document" means. Surely this doesn't declare systems with maintenance windows non-conformant? - Section 4.5 - Fourth paragraph, I'm confused about why "rejected with a 502 (Bad Gateway)" is a SHOULD, and not a MUST. SHOULDs are really "MUST, except in certain situations", and I couldn't come up with a "certain situation" where a client would be happy that it didn't get a 502. This section is very picky about SHOULDs (see last paragraph in the section for an excellent example), so I'm curious about why the 502 isn't a MUST. draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt - Section 3 - "How the compositor treats XCAP based inputs with respect to SIP PUBLISH based inputs is a matter of compositor policy, which is beyond the scope of this specification" - is there no guidance that can be provided to implementors? If the answer is that this is too application-specific for guidance, I'm visualizing a world where half the implementors override XCAP information with PUBLISH information, while half do not, and astonishment ensues, not interoperability. Even a SHOULD pointing one direction would be nice.