Document: draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt Review: Spencer Dawkins Date: 25 februari 2005 I've been in touch with Ted and the editors for this draft, and they have considered my question about document set organization, so I'm reporting the current version as ready for publication as Proposed Standards. ----- Original Message ----- From: "Ted Hardie" To: "Spencer Dawkins" ; ; Cc: ; ; Sent: Tuesday, February 22, 2005 3:49 PM Subject: Re: IETF last call issue on draft-ietf-simple-xcap-pidf-manipulation-usage > Based on this, I've issued a ballot for this document and added it to > the 3/3/2005 > agenda; if Harald would like to DISCUSS the issues raised by the > review, > I assume he will do so. I don't really want to get to far into the > issues > with followup, since the new General AD will no doubt have ideas to > share. > regards, > Ted > > At 10:40 PM -0600 2/18/05, Spencer Dawkins wrote: >> Markus and Jonathan, >> >> Somewhere deep in my review I remembered to say >> >>> >> I am not, of course, a Genius of XCAP, or of SIMPLE... >> >> so I think you guys are the right guys to figure out what goes in >> which document. My apologies for expecting you to read my mind, >> rather than actually saying so! Best wishes with the next telechat. >> >> And my extreme apologies if my review slowed anything down - I >> haven't quite figured out all the laces in the sneakers of Gen-ART >> review circulation yet. >> >> Actually, this morning the Gen-ART reviewers were discussing who we >> send what reviews to, and similar topics like "providing feedback >> from author/editor interaction". At the dawn of Gen-ART, we only sent >> our reviews to Harald, so we didn't really have a plan about how to >> follow up on the reviews (if Harald thought we raised a real concern, >> he placed a DISCUSS on the draft and took it from there). I've been >> sending them to others more recently, in case there were questions, >> but haven't thought things through to the end game! >> >> If you have opinions about what would be most helpful to you/the SIP >> community/the IETF, please send 'em to Avri Doria, who is currently >> coordinating Gen-ART. >> >> Spencer >> >> ----- Original Message ----- From: >> To: ; >> Cc: ; ; >> ; >> Sent: Friday, February 18, 2005 9:13 AM >> Subject: IETF last call issue on >> draft-ietf-simple-xcap-pidf-manipulation-usage >> >> >> Hi Spencer and Johathan, >> >> XCAP PIDF manipulation application usage draft was in IETF last call >> a while ago. Spencer raised an important point about the draft, >> namely how the presence data set by XCAP is related to data published >> using SIP PUBLISH. >> >> Currently the draft says that this is entirely a matter of the >> composition policy, which is partly addressed in Jonathan's new draft >> http://www.ietf.org/internet-drafts/draft-rosenberg-simple-presence- >> processing-model-00.txt, partly left as a future work item in SIMPLE. >> I suppose the referenece in XCAP PIDF draft should be updated to >> point to Jonathan's new draft, but can remain an informational >> referece. >> >> Also I propose that Jonathan would add some explicit text about XCAP >> PIDF manipulation as one of the sources of presence data, since >> currently the processing-model only talks about SIP PUBLISH. >> >> Is this acceptable? Or, should I address the issue in the draft >> directly. I think we have discussed this rather extensively on SIMPLE >> WG mailing list and keeping the current split is according to the >> consensus there. (I agree with Spencer's concern, but unfortunately >> we have not been able to agree on this in SIMPLE. We have been forced >> to postpone the issue for future work. And from the point of view of >> XCAP PIDF manipulation draft I think it is OK, the issue really can >> be left outside the scope of the draft.) >> >> If you agree, me and Eva can create a revised version with the new >> reference and some slight rewording, but not saying anything >> normative about the composition. >> >> Regards, >> Markus >> >>> -----Original Message----- >>> From: ext Ted Hardie [mailto:hardie@qualcomm.com] >>> Sent: 18 February, 2005 08:47 >>> To: Isomaki Markus (Nokia-TP/Espoo); hisham.khartabil@telio.no; >>> rjsparks@nostrum.com >>> Cc: Leppanen Eva-Maria (Nokia-NET/Tampere) >>> Subject: Re: PIDF manipulation draft revision? >>> >>> >>> Hi Markus, >>> Sorry for the delay in replying. Basically, I hadn't seen >>> an agreement from Spencer for this fix or from Jonathan saying >>> that he agreed that putting it in draft-simple-presence-data-model >>> would be the right approach. If I missed that traffic, sorry; can >>> you send copies? If not, we can ping Jonathan and Spencer >>> to confirm this approach works. Also, the presence data model >>> is currently an informative reference; would it stay there or >>> become normative after this change? >>> regards, >>> Ted >>> >>> At 5:35 PM +0200 2/17/05, wrote: >>>> Hi, >>>> >>>> I've noticed that the XCAP PIDF manipulation draft, >>>> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pi >>> df-manipulation-usage-02.txt, >>>> authored by myself and Eva-Maria LeppŠnen, is in the state "Revised >>>> ID needed" in the I-D tracker. >>>> >>>> I haven't figured out what the issue is that the revision should >>>> address. The only comment I've received was from Spencer Dawkins, >>>> see the attachment. As you see from my reply, I considered the >>>> >issue >>>> being outside the scope of our particular draft. >>>> >>>> Can someone help on what kind of revision is expected? >>>> >>>> Regards, >>>> Markus >>>> >>>> >>>> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 >>>> Content-class: urn:content-classes:message >>>> MIME-Version: 1.0 >>>> Content-Type: text/plain >>>> Subject: RE: XCAP Gen-ART Review for Proposed Standard >>>> Date: Tue, 4 Jan 2005 16:32:07 +0200 >>>> Message-ID: >>> >>>> X-MS-Has-Attach: >>>> X-MS-TNEF-Correlator: >>>> Thread-Topic: XCAP Gen-ART Review for Proposed Standard >>>> Thread-Index: AcTwUXb6wKnDHg0VTfaYycq1C8Xu+wCF7pQg >>>> From: >>>> To: , >>>> >>>> Cc: , >>>> , >>>> , >>>> , >>>> , >>>> , >>>> >>>> >>>> Hi Spencer, >>>> >>>> Thanks for your review. >>>> >>>> Answering to your comment on >>> draft-ietf-simple-xcap-pidf-manipulation-usage-02 >>>> >>>>> - 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. >>>> >>>> I agree that the situation at the moment is quite vague with this. >>>> In my opinion the best place to make any definition on this would >>>> >be >>>> the SIMPLE Presence Data Model draft, >>>> http://www.ietf.org/internet-drafts/draft-ietf-simple-presenc >>> e-data-model-01.txt. >>>> That draft aims to define the default composition operations. At >>>> >the >>>> moment I think it only considers SIP based publications, so perhaps >>>> it would be good to have XCAP based presence source specifically >>>> mentioned there. >>>> >>>> Markus >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Spencer Dawkins [mailto:spencer@mcsr-labs.org] >>>>> Sent: 02 January, 2005 00:31 >>>>> To: gen-art@alvestrand.no >>>>> Cc: Ted Hardie; Jonathan Rosenberg; Isomaki Markus >>> (Nokia-TP/Espoo); >>>>> Leppanen Eva-Maria (Nokia-NET/Tampere); >>>>> Gonzalo.Camarillo@ericsson.com; >>>>> Dean Willis; Rohan Mahy; Allison Mankin >>>>> Subject: XCAP Gen-ART Review for Proposed Standard >>>>> >>>>> >>>>> Hi, Harald, >>>>> >>>>> 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. >>>>> >>>>> >>>>> >