Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Bob Braden wrote: Jim, Understood, but the RFC Editor does care how it flows. We would like to get it as nearly right as possible, going out of the gate. Bob Braden ... For tracking purposes, I just published draft-reschke-hab-00 (http://greenbytes.de/tech/webdav/draft-reschke-hab-00.html), which contains the headers and boilerplates for the 19 cases Sandy has identified. Note that the contents for these cases is auto-generated by the experimental version of rfc2629.xslt. I plan to update rfc2629.xslt and this draft as the RFC Editor fine-tunes the text for draft-iab-streams-headers-boilerplates. This will give us easy-to-read diffs on tools.ietf.org. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Gen-art] Gen-ART LC review of draft-dusseault-http-patch-15.txt
I'm quite happy for the subject matter experts to decide between these two approaches. Thanks Brian On 2009-11-27 01:46, Julian Reschke wrote: Roy T. Fielding wrote: On Nov 17, 2009, at 11:53 AM, Brian E Carpenter wrote: These are the sort of changes that would, I believe, give sufficient indication to a would-be user of PATCH of how to make it somewhat safe. Personally I'd prefer to see it made more prominent by starting with something like: Clients requiring to verify the consistent application of a patch document to a known entity SHOULD first acquire an ETag... Rationale: the use of a normative keyword will draw the attention of implementors who might otherwise not think about this issue. It would also be wrong, because it is neither a requirement for interoperation nor a potential for causing harm (RFC 2119). Aside from which, it makes the original purpose of PATCH non-compliant with its own specification. The purpose of PATCH is to request that the server apply a set of changes to the current state of the target resource. The assumption that these changes will be dependent on a specific prior representation of that resource is false. The server is fully capable of detecting and reporting conflicts when they occur with the current state, as only truly known by the server. In other words ... If the client wants to prevent the PATCH method from being applied to a resource for which the state has changed since the last state known by the client, then it SHOULD use one or more of the conditional request mechanisms of HTTP (If-Match and If-Unmodified-Since request headers [RFC2616]) or WebDAV (If request header [RFC4918]) with the associated metadata from that prior resource state. However, if the patch media type contains its own mechanism for detecting conflicts, such as embedded context or metadata designed to allow non-overlapping changes to be safely applied, then the conditional request mechanisms SHOULD NOT be used with PATCH because they would interfere with collaborative applications, such as shared editors and whiteboards. FTR, the prior sentence, that PATCH is somehow more likely to result in corrupted state than a PUT, is simply false for any patch format that contains context or post-application integrity checks. The only reason it was in the spec is because earlier versions assumed a patch format that contains nothing but byte-vector manipulations. It should be removed, or at least altered to be factual. Roy In the meantime, a new draft was published, see http://tools.ietf.org/html/draft-dusseault-http-patch-16 and http://tools.ietf.org/rfcdiff?url2=draft-dusseault-http-patch-16.txt for the diffs. The new text is: A PATCH request can be issued in such a way as to be idempotent, which also helps prevent bad outcomes from collisions between two PATCH requests on the same resource in a similar timeframe. Collisions from multiple PATCH requests may be more dangerous than PUT collisions, because some patch formats need to operate from a known base point or else corrupt the resource. Clients using this kind of patch application SHOULD acquire a strong ETag [RFC2616] for the resource to be modified, and use that ETag in the If-Match header on the PATCH request to verify that the resource is still unchanged. If a strong ETag is not available for a given resource, the client can use If-Unmodified-Since as a less-reliable safeguard. This text is still problematic, in that 1) It suggests that the client is in control of the etag (...acquiere a strong etag...); however, the client has no control over this at all; it's the server who decides, and also it's the server who's in charge in deciding what type of etags it accepts in which operations. 2) It doesn't mention that WebDAV defines another conditional header which doesn't have the limitations of If-Match (per RFC2616, not HTTPbis). I found Roy's proposal both easy to understand and correct, and like to see it (or something more similar to it than the current text) being used. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-melnikov-imap-keywords-06
Samuel Weiler wrote: On Wed, 18 Nov 2009, Alexey Melnikov wrote: And for the common-use: Registration of an IMAP keyword intended for common use (whether or not they use the $ prefix) requires Expert Review [RFC5226]. IESG appoints one or more Expert Reviewer, one of which is designated as the primary Expert Reviewer. IMAP keywords intended for common use SHOULD be standardized in IETF Consensus [RFC5226] documents. ... In cases when an IMAP Keyword being registered is already deployed, Expert Reviewers should favour registering it over requiring perfect documentation. Would it be better to say: requires either IETF Consensus or Expert Review? Not everybody is subscribed to ietf or ietf-announce mailing lists, so I would like for all common use registrations to go through the expert. I don't like the logic (while not everybody is subscribed to the lists, your expert surely could be, People have complained about traffic on the ietf mailing list during plenaries. and it's easy from an AD to punt the doc to the expert). That part is easy, yes. That said, since you want everything to go through the expert, to avoid confusion, I suggest removing the citation to the inapplicable 5226 metric: IETF Consensus [RFC5226]. Ok, I will try to clarify. (For example: do the registrations made in this doc have to go through Expert Review? No, because they are a part of the document that creates the registry ;-). Isn't it enough to have them in a consensus doc?) And how do you expect the expert to encourage/enforce the SHOULD, given the favour registering it over requiring perfect documentation guideline? Again, the current text isn't as clear as I'd like. This is intentional. This is a judgment call by the expert. This sounds inconsistent. Yes, but it is a fact of life. It is not worse than the current situation where people just deploy stuff without bring it to any standard mailing list. I'm hearing it's within the scope of the expert's judgement to require an IETF Consensus doc and In cases when an IMAP Keyword being registered is already deployed, Expert Reviewers should favour registering it over requiring perfect documentation. If I were an implementer who got told you need a consensus doc, I'd be more than a little tempted to go ahead and deploy, then reapply for the registration. Well, if one works for Microsoft, Google, Mozilla, etc. (not trying to pick on anybody), then one does it every time. Hopefully Expert Review is low enough bar to tempt people (if tempt is the right word here at all) to register. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-melnikov-imap-keywords-06
--On Saturday, November 28, 2009 9:29 PM + Alexey Melnikov alexey.melni...@isode.com wrote: ... I'm hearing it's within the scope of the expert's judgement to require an IETF Consensus doc and In cases when an IMAP Keyword being registered is already deployed, Expert Reviewers should favour registering it over requiring perfect documentation. If I were an implementer who got told you need a consensus doc, I'd be more than a little tempted to go ahead and deploy, then reapply for the registration. Well, if one works for Microsoft, Google, Mozilla, etc. (not trying to pick on anybody), then one does it every time. Hopefully Expert Review is low enough bar to tempt people (if tempt is the right word here at all) to register. Sam, For whatever it is worth, the above exchange goes to the very root of the question of what we think our registration procedures and registries are for, at least when there isn't a scarcity of possible identifiers. One theory is that they should be designed to prevent garbage, or warn people against garbage by the fact that something isn't registered. I think we've seen ample evidence that theory doesn't work, with your comments and Alexey's above both constituting examples. The other is that the main purpose of registration is to provide sufficient information and documentation to promote interoperability by virtue of encouraging people to avoid using the same identifier for different purposes. I'm more optimistic about the second than the first, but it calls for a fairly low bar on registrations. Neither model has much to do with security: registration, no matter how high or low the threshold, won't prevent an attack if someone is inclined to misuse or reuse an identifier in a malicious way. Nor will non-registration help avoid someone finding out what an identifier looks like an attacking whatever it represents if one were inclined to do that... only the most dedicated believer in security through obscurity could believe that non-registration is helpful in that regard and it would be a stretch even then. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
On 2009-11-24 06:44, Steven M. Bellovin wrote: On Mon, 23 Nov 2009 08:16:49 -0500 Scott Brim scott.b...@gmail.com wrote: Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM: John-Luc said he is bound by confidentiality obligations from his company, and I think the same applies to most employees of larger organizations. There is nothing explicit in BCP 79 to protect against this apparent conflict of interest, or is there? Since disclosure is required for anyone submitting documents or participating in IETF discussions, a person who does not disclose IPR for this reason, or any other reason, must not contribute to or participate in IETF activities with respect to technologies that he or she reasonably and personally knows to be Covered by IPR which he or she will not disclose. Precisely. The conflict Simon mentions was of course known to most of the WG; that's one reason we have that clause. IMHO, BCP79 creates no particular problem for corporate lawyers who are instructed by their corporate management to ensure that the company behaves as a good citizen in its standards activities. This is strongly in the company's interests, anyway, since failure to disclose when required by a standards process threatens the validity of the patent. It really is not the IETF's problem. It is a problem for a company that chooses not to behave as a good citizen. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
