ietf-smtp
[Top] [All Lists]

Re: Conflicting Enhanced Status Codes between RFC 4468 and draft-siemborski-rfc2554bis

2007-03-13 11:37:49

Alexey Melnikov wrote:

  [IETF consensus method]
Published RFC is IMO simpler, they can link to a RFC in the registry.

I agree.  I prefer a Standard Track or Experimental RFC.

In DKIM base they finally used this (slightly worse) formula:

| In all cases, new values are assigned only for values that have
| documented in a published RFC having IETF Consensus [RFC2434].

With that they got rid of "independent RFCs" (one AD wanted this)
including independent experiments.  Your proposal would still allow
"independent experiments", it has no 1:1 correspondence to a rule
proposed in 2434bis.  Trying to use 2434bis chapter 4 terminology 
I get this for your proposal:

- be registered with IANA under the IETF Consensus method.
+ be registered with IANA after IETF review [2434bis] or publication
+ in an independent experimental RFC.

2434bis says that "IETF review" is the same as 2434 "IETF Consensus".

Adding "or in an independent experiment" is nice, unfortunately too
late for DKIM base.  The original "RFC" in DKIM caused a [Discuss]
proposing "standards track", but that would kill _all_ experiments.

Now 2554bis needs a normative reference to your draft,
It would depend on the order in which documents will be published.

Yes, if 2554bis is published before (using the conflicting status
code as is) the registry I-D could update both 4468 and 2554bis.
OTOH you'd then get a fresh 2554bis updated immediately after its
publication.

John proposed to obsolete the conflicting code by two new codes
in your draft.

I was expecting a table listing existing entries. This exercise
would at least uncover other conflicts, if any. (I do volunteer
for this part)

Tony's I-D says that you'd have to join the codes defined in 3463,
3886, and 4468 (+ errata, if any exist)...

...BUT...

...does the proposed "permanent" registry based on RFCs actually
help to avoid similar conflicts in the future ?  As long as a new
status code only exists as proposal in an I-D it's hard to see if
that's in one or more (potentially conflicting) I-Ds.

For the header fields there's an additional "provisional registry",
where values can be added as soon as they're published "somewhere"
(e.g. in an I-D), and moved from "provisional" to "permanent" when
it's a "standard" (of some kind, header fields aren't too critical).

For various reasons I'm sure that this is far too complex for the
status codes.  But Tony's I-D only helps to detect RFC conflicts,
it doesn't prevent I-D conflicts.  That should be noted somewhere.

Frank