Re: [Gen-art] Gen-ART LC/Telechat review of draft-freed-sieve-in-xml-05
On Aug 16, 2009, at 11:01 AM, Ned Freed wrote: [...] >> it would be helpful to have a sentence or two somewhere (maybe >> in the intro) to explicitly say so. My confusion might be around the >> meaning of the term "client" in this context. > > No, I think your confusion is that you read a lot more into the text > than it > actually says. There's a pretty big difference between "no semantic > understanding whatsoever" and "an incomplete semantic understanding'. I think the confusion is that the text says very little one way or the other. You have assumptions in mind about the semantic knowledge of an editor that are not explicitly stated. On the contrary, we have made _no_ assumptions whatsoever about it. And the draft reflects that. You, OTOH, appear to have approached this with a set of assumptions I for one frankly don't comprehend in your head. Perhaps - and this is just speculation on my part - this is because, as you have stated, you haven't done much work using XML tools. If so, then you need to understand that this document assumes considerable familiarity with XML and the tools used to manipulate it. And given the topic of the document this is a perfectly reasonable assumption to make IMO. A reader that was not privy to the process of creating this draft may come with a different set of assumptions, and may not draw the inferences you expect them to. In my case, it seemed counter-intuitive that an implementer would be willing to implement sieve semantics but unwilling to deal with the syntax. And this is a case in point. The purpose of this specification is to provide a means of representing Sieve using an alternate syntax without changing any of the language semantics. As such, the audience is *exactly* the group of people who are "willing to implement sieve semantics but unwilling to deal with the syntax". (And from all indications - there are now alternative XML representatiions for many other applications formats - this is a pretty large group.) I have to say that approaching such a specification with the idea that it's entire goal is counterintuitive is a pretty good recipe for confusion on your part. And I don't think any amount of clarifying prose can possibly assist you in dealing with such a fundamental expectation mismatch. Your "template" comment below illustrates a case where that makes more sense. Again, the extent to which an editor understands and can deal with Sieve semantics is largely orthogonal to the representation format. There are extant Sieve editors that don't use the XML representation and which understand essentialy no Sieve semantics at all - they are controlled by embedded comments in special formats only, and treat the Sieve material between the comments as opaque. Just think how easy it would be for some other Sieve generation facility to confuse such an editor. > >> Is the expectation that >> an "editor" must be semantically aware of sieve, but a processor does >> not (beyond the list of "controls")? > > The expectation is that the amount of semantic understanding an > editor is going > to need will very much depend on the range of operations the editor > is able to > perform. Simple template-based systems will only manipulate labelled > blocks of > Sieve code without any understanding of what that code does. A more > sophisticated editor might need to have a detailed knowledge of how > blocks in > Sieve work, or how to build conditional expressions, or even the > details > sematics of various tests and actions. That paragraph clarifies a lot. I think it would be helpful to include it in the draft. I disagree. The above paragraph might make sense to have in some sort of Sieve usage document. It's unnecessary and distracting here. > >> ... > >> Instead of round trip "conversion", I should have said round-trip >> "editing". My concern is, if I create a script using Editor A, then >> later edit it with Editor B, any metadata created by Editor A is >> likely to be lost. > > And that's a valid concern to have. Again, there are going to be > cases where > one editor has no choice but to strip the information added by > another. This is > simply how things are; there's nothing this or any other > representation scheme > can do to eliminatte this possibility. > >> Is that the intent? > > It's not a matter of intent. It is simply an unavoidable reality. > >> If so, it's probably worth >> mentioning that an editor needs to be able to deal rationally with >> the >> loss of its own metadata. > > First, while it is certainly desireable for all editors to have this > characteristic, there are going to be cases where it cannot possibly > work this way. So this can't be a requirement. So am I understanding correctly that it's unreasonable to expect an editor to just leave metadata alone if it doesn't understand it, it depends on the context. Hopefully the XML format will help make it a little easier to do this in some cases. But certainly not
Re: [Gen-art] draft-ietf-ntp-autokey-06.txt
Russ - would you be willing to clear your DISCUSS and capture Joel's new issues in a COMMENT? - Ralph On Jul 27, 2009, at 4:56 AM 7/27/09, Joel M. Halpern wrote: This document is nearly ready for publication as an Informational RFC. While my comments have been resolved, some minor issues apparently crept in during the editing process.. These are small enough that they can probably be dealt with in notes to the RFC Editor if no other issues are found. However, they are sufficiently ambiguous that they should not be left for rediscovery by the RFC Editor. Two individual sentences became truncated (Section 7, first paragraph "was created." => "was." and section 8, third bullet "the server."=>"the.") Section 8 on the Sign exchange previously said that the information was signed using the private key. Now it says that it is signed using the public key. As I understand it, the signature is generated with the private key to be verified with the public key. I am not sure what the right words in the paragraph would be. (I was happy with "private key" before since the signer used his own private key.) In the paragraph on the extension field parser length calculation, with the text beginning: "If greater than 22 an extension field is present. If the length is .." has two minor issues. I believe it would be clearer if it said "If the remaining length is greater than 22 an extension field is present. If the remaining length is ..." Yours, Joel M. Halpern Russ Housley wrote: Joel: Please take a look at the updated document *Discuss (2009-06-15) * The Gen-ART Review by Joel Halpern on 5-June-2009 has lead to some discussion with the authors. Not all of the issues have been resolved, but it is clear that some changes to the document are needed. The following issues are still unresolved. The usage within Autokey of the extension field need description early in the document. Paragraph 3 of Section 10 reserves seven values (1-7) Autokey. The "Field Type" field performs two roles: identification as an Autokey extension and defining the type within Autokey. Section 11.1 includes a 16 bit Digest / Signature NID. There is no description of how this is used. The wording on hierarchy in section 5, paragraph 3 is the opposite of what is shown in the figure. (The figure matches expectations, where a client of one group operates as the TH of a group operating at a lower stratum.) In Section 10, the paragraph that begins "[T]he extension field parser initializes a pointer..." is incorrect. The "length" by which the pointer is increment is the length in the extension header, not the length computed by subtracting the NTP header from the packet length. In figure 5, it would help the reader if the groups and hosts had different names. (Even just calling the groups Alice-Group and Carol-Group would help.) In section 5, in the description of "[t]he steps in hiking the certificate trails...", in step 1, in the second sentence, please add language to make it clear that the server is "exchanging host names and negotiating..." with is the server from whom it is getting information. Section 8 should be moved earlier in the document. Early parts of the document assume an understanding of properties of the system which have not been described yet. Section 11.6 (Security Considerations) is supposed to be a top-level section. X-Original-To: hous...@vigilsec.com Delivered-To: hous...@vigilsec.com X-Virus-Scanned: amavisd-new at smetech.net X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 required=3.5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] From: internet-dr...@ietf.org To: ntp-cha...@tools.ietf.org, draft-ietf-ntp- auto...@tools.ietf.org,rdr...@cisco.com,hous...@vigilsec.com,tim.p...@nist.gov ,pasi.ero...@nokia.com,adrian.far...@huawei.com Subject: New Version Notification - draft-ietf-ntp-autokey-06.txt Date: Wed, 8 Jul 2009 05:00:02 -0700 (PDT) New version (-06) has been submitted for draft-ietf-ntp- autokey-06.txt. http://www.ietf.org/internet-drafts/draft-ietf-ntp-autokey-06.txt Sub state has been changed to AD Follow up from New Id Needed Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-ntp-autokey-06 IETF Secretariat. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC/Telechat review of draft-freed-sieve-in-xml-05
On Aug 16, 2009, at 11:01 AM, Ned Freed wrote: [...] it would be helpful to have a sentence or two somewhere (maybe in the intro) to explicitly say so. My confusion might be around the meaning of the term "client" in this context. No, I think your confusion is that you read a lot more into the text than it actually says. There's a pretty big difference between "no semantic understanding whatsoever" and "an incomplete semantic understanding'. I think the confusion is that the text says very little one way or the other. You have assumptions in mind about the semantic knowledge of an editor that are not explicitly stated. A reader that was not privy to the process of creating this draft may come with a different set of assumptions, and may not draw the inferences you expect them to. In my case, it seemed counter-intuitive that an implementer would be willing to implement sieve semantics but unwilling to deal with the syntax. Your "template" comment below illustrates a case where that makes more sense. Is the expectation that an "editor" must be semantically aware of sieve, but a processor does not (beyond the list of "controls")? The expectation is that the amount of semantic understanding an editor is going to need will very much depend on the range of operations the editor is able to perform. Simple template-based systems will only manipulate labelled blocks of Sieve code without any understanding of what that code does. A more sophisticated editor might need to have a detailed knowledge of how blocks in Sieve work, or how to build conditional expressions, or even the details sematics of various tests and actions. That paragraph clarifies a lot. I think it would be helpful to include it in the draft. ... Instead of round trip "conversion", I should have said round-trip "editing". My concern is, if I create a script using Editor A, then later edit it with Editor B, any metadata created by Editor A is likely to be lost. And that's a valid concern to have. Again, there are going to be cases where one editor has no choice but to strip the information added by another. This is simply how things are; there's nothing this or any other representation scheme can do to eliminatte this possibility. Is that the intent? It's not a matter of intent. It is simply an unavoidable reality. If so, it's probably worth mentioning that an editor needs to be able to deal rationally with the loss of its own metadata. First, while it is certainly desireable for all editors to have this characteristic, there are going to be cases where it cannot possibly work this way. So this can't be a requirement. So am I understanding correctly that it's unreasonable to expect an editor to just leave metadata alone if it doesn't understand it, and it's also unreasonable to expect an editor to behave in a sane manner if its metadata gets stripped? It seems like there are three choices here: You can expect editors to preserve metadata from other editors, you can allow stripping of metadata and expect editors to deal rationally with its loss, or you can expect that if a user uses more than one editor over the lifetime of a script, one or both of the editors is likely to fail in a non- graceful way. Did the working group really choose the third option? Second, even if it were appropriate to make this a requirement, this document isn't the place for it. All this document does is describe an XML representation for Sieve. All of the requirements it imposes are directed at the representation and the process of converting to or from that representation. But since there is no requirement that a Sieve editor use this XML representation at all - and in practice most extant Sieve editors operate directly on the native Sieve format - imposing requirements on editors here makes little if any sense. I fail to understand why it is acceptable to put requirements on processors but not on editors. Certainly no one would expect an editor that does not implement this specification to be bound by any requirements in it. For that matter, you already have (admittedly weak) 2119 language referring to editors But if you are unwilling to place normative requirements around this, it would still help quite a bit to have some non-normative guidance to the effect that, since there is no requirement for an editor to preserve metadata from another editor, an editor implementation can expect to have its metadata removed from any given script. It it does not handle this gracefully, bad user experiences are likely to result. (I can think of reasonable use cases that would involve this--perhaps I create the script with an editor on my laptop, but later need to modify it using an editor on a smart phone...). Again, there is absolutely no doubt that being able to use multiple editors on the same sieve and have them all work happily toget
Re: [Gen-art] Gen-ART review of draft-ietf-vcarddav-webdav-mkcol-05
Hi, Cyrus,
This works for me.
Thanks for getting back to me quickly, and I hope you enjoyed your vacation.
Spencer
Hi Spencer,
Thanks for your review - I was on vacation last week so I am only getting
around to replying now.
--On August 7, 2009 6:36:41 AM -0500 Spencer Dawkins
wrote:
Comments identified as "Spencer (clarity)" are provided for editors, but
are not part of the Gen-ART review.
Abstract
This specification extends the Web Distributed Authoring and
Versioning (WebDAV) MKCOL method to allow collections of arbitrary
resourcetype to be created and to allow properties to be set at the
same time.
Spencer (clarity): I know that RFC 4918 didn't provide an expansion for
MKCOL until about page 46 (or maybe 25, in passing), but since MKCOL
appears in the abstract for this document, it might be helpful to
s/MKCOL/MKCOL ("Make Collection")/ here. MKCOL is defined at first use in
the Introduction, so that's fine - this is only a suggestion about the
abstract.
Sure - seems reasonable. Change done in my working copy.
3. WebDAV extended MKCOL
The WebDAV MKCOL request is extended to allow the inclusion of a
request body. The request body is an XML document containing a
single DAV:mkcol XML element as the root element. The Content-Type
Spencer (minor): if I'm reading this paragraph correctly, I'd suggest
"The request body is an XML document that MUST contain a single DAV:mkcol
XML element as the root element" here - the last sentence in this
paragraph makes me think the requirement is normative, but it doesn't
look normative to 2119 scanners :-)
As per comments from Julian I won't make this change.
request header MUST be set appropriately for an XML body (e.g., set
to "text/xml" or "application/xml"). XML-typed bodies for an MKCOL
request that do not have DAV:mkcol as the root element are reserved
for future usage.
As per the PROPPATCH method ([RFC4918], Section 9.2), servers MUST
process any DAV:set instructions in document order (an exception to
the normal rule that ordering is irrelevant). Instructions MUST
either all be executed or none executed. Thus, if any error occurs
Spencer (clarity): this sentence reads roughly to me, and it's 2119
language, so needs to be clear. I suggest "The set of instructions MUST
be executed atomically; either all are executed or none are executed".
The text here is an exact copy of that in 4918. Strictly speaking all
instructions are executed, it is just that some succeed and some fail.
Perhaps better text is:
"If any one instruction fails to execute successfully, then all
instructions MUST fail (i.e., either all succeed or all fail)".
during processing, all executed instructions MUST be undone and a
proper error result returned. Failure to set a property value on the
collection MUST result in a failure of the overall MKCOL request -
i.e. the collection is not created.
3.5. Example: Successful Extended MKCOL Request
Spencer (minor): Perhaps this should be s/Successful/Unsuccessful/? It's
returning a 403/424 :D
Fixed.
4. Replacing Existing MKxxx Methods
Spencer (clarity): Hmm. This section (and 4.1, and 4.1.1) aren't quite
about REPLACING existing MKxxx methods, but more like "Providing MKxxx
functionality using extended MKCOL". Would that be clearer? The current
text in 4.1 sent me looking to see whether "replacement" meant
"deprecation" (it doesn't, if I'm reading clearly), for example.
Well ultimately I would like to see MKCALENDAR deprecated in favor of
extended MKCOL - however, given the ever growing deployments of CalDAV
that is probably not going to happen any time soon.
So, I have changed the title to:
"Using Extended MKCOL as an Alternative to MKxxx Methods"
and changed "replace" to "alternative for" in a couple of places.
--
Cyrus Daboo
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-vcarddav-webdav-mkcol-05
Hi Spencer,
Thanks for your review - I was on vacation last week so I am only getting
around to replying now.
--On August 7, 2009 6:36:41 AM -0500 Spencer Dawkins
wrote:
Comments identified as "Spencer (clarity)" are provided for editors, but
are not part of the Gen-ART review.
Abstract
This specification extends the Web Distributed Authoring and
Versioning (WebDAV) MKCOL method to allow collections of arbitrary
resourcetype to be created and to allow properties to be set at the
same time.
Spencer (clarity): I know that RFC 4918 didn't provide an expansion for
MKCOL until about page 46 (or maybe 25, in passing), but since MKCOL
appears in the abstract for this document, it might be helpful to
s/MKCOL/MKCOL ("Make Collection")/ here. MKCOL is defined at first use in
the Introduction, so that's fine - this is only a suggestion about the
abstract.
Sure - seems reasonable. Change done in my working copy.
3. WebDAV extended MKCOL
The WebDAV MKCOL request is extended to allow the inclusion of a
request body. The request body is an XML document containing a
single DAV:mkcol XML element as the root element. The Content-Type
Spencer (minor): if I'm reading this paragraph correctly, I'd suggest
"The request body is an XML document that MUST contain a single DAV:mkcol
XML element as the root element" here - the last sentence in this
paragraph makes me think the requirement is normative, but it doesn't
look normative to 2119 scanners :-)
As per comments from Julian I won't make this change.
request header MUST be set appropriately for an XML body (e.g., set
to "text/xml" or "application/xml"). XML-typed bodies for an MKCOL
request that do not have DAV:mkcol as the root element are reserved
for future usage.
As per the PROPPATCH method ([RFC4918], Section 9.2), servers MUST
process any DAV:set instructions in document order (an exception to
the normal rule that ordering is irrelevant). Instructions MUST
either all be executed or none executed. Thus, if any error occurs
Spencer (clarity): this sentence reads roughly to me, and it's 2119
language, so needs to be clear. I suggest "The set of instructions MUST
be executed atomically; either all are executed or none are executed".
The text here is an exact copy of that in 4918. Strictly speaking all
instructions are executed, it is just that some succeed and some fail.
Perhaps better text is:
"If any one instruction fails to execute successfully, then all
instructions MUST fail (i.e., either all succeed or all fail)".
during processing, all executed instructions MUST be undone and a
proper error result returned. Failure to set a property value on the
collection MUST result in a failure of the overall MKCOL request -
i.e. the collection is not created.
3.5. Example: Successful Extended MKCOL Request
Spencer (minor): Perhaps this should be s/Successful/Unsuccessful/? It's
returning a 403/424 :D
Fixed.
4. Replacing Existing MKxxx Methods
Spencer (clarity): Hmm. This section (and 4.1, and 4.1.1) aren't quite
about REPLACING existing MKxxx methods, but more like "Providing MKxxx
functionality using extended MKCOL". Would that be clearer? The current
text in 4.1 sent me looking to see whether "replacement" meant
"deprecation" (it doesn't, if I'm reading clearly), for example.
Well ultimately I would like to see MKCALENDAR deprecated in favor of
extended MKCOL - however, given the ever growing deployments of CalDAV that
is probably not going to happen any time soon.
So, I have changed the title to:
"Using Extended MKCOL as an Alternative to MKxxx Methods"
and changed "replace" to "alternative for" in a couple of places.
--
Cyrus Daboo
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-ltans-dssc-10.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ltans-dssc-10.txt Reviewer: Miguel Garcia Review Date: 18 Aug 2009 IETF LC End Date: IESG Telechat date: (if known) Summary: The document is ready for publication as a standards track RFC. I reviewed version -08 of this document, raising a number of issues. I must say that all off them have been successfully addressed. I have verified that the XML schema and the example correctly validates (but see comment below) so the document is ready for publication. There is only a typographical error that should be fixed. Major issues: none Minor issues: none Nits/editorial comments: - Appendix B, the XML schema. Locate the "EvaluationType" element, towards the end of page 31. The text reads: ^^ Notice the duplication of "minOccurs" attribute in the "xs:any" element. So please, delete one of the duplicated minOccurs attributes. Once this error is fixed, the XML schema and the example correctly validates. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
