Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!

2009-11-28 Thread Julian Reschke

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

2009-11-28 Thread Brian E Carpenter
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

2009-11-28 Thread Alexey Melnikov

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

2009-11-28 Thread John C Klensin



--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)

2009-11-28 Thread Brian E Carpenter
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