On 5/3/2014 4:35 PM, Jim Fenton wrote:
On 05/01/2014 11:43 AM, Dave Crocker wrote:
On 5/1/2014 1:36 PM, Jim Fenton wrote:
I'd like to understand the relationship of RFC 4846, which is
Informational, with RFC 5792/BCP 92 here. The latter gives IESG 5
options for review of independent submissions for conflicts with the
IETF standards process, such as:
5. The IESG has concluded that this document extends an IETF protocol
in a way that requires IETF review and should therefore not be
published without IETF review and IESG approval.
Since DMARC does not extend any existing IETF protocol, how is that
reference useful here?
I was citing one of the five options IESG has. For brevity I chose not
to cite all five (everyone can find them in RFC 5742, not 5792 which was
a typo).
But since you bring it up, DMARC does alter (extend) SMTP, for example
by its recommendation in Section 10.1 that messages containing a single
RFC5322.From with multiple entities be rejected. It might be argued
that's not a significant limitation, but that's what the IETF review is
all about.
This confuses advice about policies for /use/ of a protocol, versus
/specification/ of the protocol itself. "Extending" means modifying the
protocol. Changing the bits over the wire; changing semantics of the
bits. Bits over the wire is the usual IETF definition of 'protocol'.
The SMTP specification makes no attempt to give comprehensive guidance
about receiver policies for rejecting or accepting mail. Nor should it.
The DMARC draft does not alter the bits over the wire.
John Levine's example of DMARC defining additional response codes is
somewhat more interesting, though I'd still class it as pretty minor,
since its not changing any major reply values.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net