W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

Re: Response to appeal by Robert Sayre dated 2006-08-29

From: Robert Sayre <rsayre@mozilla.com>
Date: Mon, 16 Oct 2006 17:47:47 +0000
Message-ID: <4533C599.50502@mozilla.com>
To: ietf@ietf.org, atom-protocol@imc.org, HTTP Working Group <ietf-http-wg@w3.org>


Sorry, I guess you're stuck with the complete nonsense in your current 
draft. Even though RFC2617 is already a draft standard.


Which mechanism will become required to implement for all HTTP/1.1 
implementations? You can't cycle at DS without picking one.


"It means what we want it to mean". Below, there are some brief 
responses to the irrelevant citations that were included.

I guess I'll head over to Apache and write some client support for their 
new HTTP security standards.


Robert Sayre

On 10/16/06, IESG Secretary <iesg-secretary@ietf.org> wrote:
 > This is the IESG response to the appeal by Robert Sayre
 > posted at
 > http://www.ietf.org/IESG/APPEALS/appeal-from-robert-sayre-08-29-2006.txt.
 > The IESG has considered Mr. Sayre's concerns and believes that by
 > requiring mandatory to implement security mechanisms the IESG is
 > continuing a long established practice with strong IETF-wide
 > community support. Acting counter to that support would require
 > evidence of a new community consensus. Some sparse recent
 > discussion on the IETF-wide list has not yet shown a change in this
 > support.
 > Therefore, we reject the appeal and hold with our original advice
 > given to the atompub working group.
 > ---------
 > Appendix: Summary of relevant IETF documents
 > RFC 3935 (BCP 95) states
 > "The benefit of a standard to the Internet is in interoperability - that
 > multiple products implementing a standard are able to work together in
 > order to deliver valuable functions to the Internet's users."
 > RFC 2026 (BCP9) requires demonstrated interoperability of all
 > features (mandatory or optional) prior to advancement to DS.
 > Although demonstrated interoperability is not required for
 > PS, it is clearly illogical to admit a spec to the standards
 > track that is by construction ineligible for DS.

Nonsense.  2616 and 2617 are already at DS.

 > Therefore, interoperability is the overall goal and all features
 > (mandatory or optional) must be designed to be interoperable.
 > RFC 2360 (BCP 22) points out the dangers of optional features:
 > "2.10 Handling of Protocol Options
 > Specifications with many optional features increase the complexity of
 > the implementation and the chance of non-interoperable
 > implementations. The danger is that different implementations may
 > specify some combination of options that are unable to interoperate
 > with each other."

HTTP authentication is specified by RFC2616/RFC2617. Furthermore, BCP 22 
describes decisions for Internet Standards Writers (read: WG), not 
Security Area Directors.

 > RFC 3365 (BCP 61) requires strong security to be available for all
 > protocols.
 > "The solution is that we MUST implement strong security in all
 > protocols to provide for the all too frequent day when the protocol
 > comes into widespread use in the global Internet.
 > ...
 > However security must be a MUST IMPLEMENT so that end users will have
 > the option of enabling it when the situation calls for it."

Yes, you have to pick something, but not everyone will pick the same thing.

 > RFC 3631 (IAB document), section 2.2, discusses "Mandatory to implement"
 > security in more detail. The key sentence is
 > "To solve this problem, the IETF requires that *ALL* protocols provide
 > appropriate security mechanisms, even when their domain of
 > application is at first believed to be very limited."
 > This is an IAB document, not a BCP, but it is a document that was
 > discussed widely prior to publication. It describes the policy 
followed by
 > the IESG for many years and endorsed by the IAB, in tandem with BCP 61.

Yes, you have to pick something, but not everyone will pick the same thing.


Robert Sayre
Received on Monday, 16 October 2006 19:22:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:47:10 UTC