Atompub,
Sorry, I guess you're stuck with the complete nonsense in your current
draft. Even though RFC2617 is already a draft standard.
HTTP-WG,
Which mechanism will become required to implement for all HTTP/1.1
implementations? You can't cycle at DS without picking one.
IESG,
"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.
thanks,
Robert Sayre
On 10/16/06, IESG Secretary <iesg-secretary(_at_)ietf(_dot_)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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf