Skip to main content

Appeal: Mandatory to implement HTTP authentication mechanism in the Atom Publishing Protocol (Robert Sayre; 2006-08-29) - 2006-08-29
Response - 2006-10-16

* To: Robert Sayre 
* Subject: Response to appeal by Robert Sayre dated 2006-08-29
* From: IESG Secretary 
* Date: Mon, 16 Oct 2006 13:07:18 -0400
* Cc: atom-syntax at, ietf-announce at

This is the IESG response to the appeal by Robert Sayre
posted at

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

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.

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."

RFC 3365 (BCP 61) requires strong security to be available for all

"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."

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.