ietf-smtp
[Top] [All Lists]

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

2007-04-10 10:58:48

Tony Hansen wrote:
 
Getting back to this draft.

I'm a bit confused by I-D.klensin-smtp-code-registry, this isn't an
intentionally competing draft, or is it ?  

IANA is directed to create the registry Mail Enhanced Status
Codes.  In the terms of [5], values of Enhanced Status Codes
must be registered with IANA under the IETF Consensus method.

Published RFC is IMO simpler, they can link to a RFC in the 
registry.
 
That *IS* the IETF Consensus method; see the definition in RFC
2434.

IMO it's very different:  "Published RFC" allows informative and
experimental RFCs submitted independently (direct to RFC editor).

IETF consensus is IMO something based on an IETF Last Call.  It's
not necessarily published as RFC.  Generally it's an "IETF last
called RFC".  If the IESG could decree "IETF consensus" without
Last Call it would be another reason why 2234bis should replace
2234 a.s.a.p.

If 2434bis gets published first, this statement should be 
revised accordingly.

Yes, the 2234bis term is "IETF review", and it clearly requires
an IETF RFC.
 
There is an issue of what to do with the values X.7.8 through
X.7.13.  These were all defined in a draft that has since 
expired (draft-newman-auth-resp-00.txt), but have been used in
other documents such as draft-siemborski-rfc2554bis.

2554bis-09 was approved some days ago, I see 2.7.0, 4.7.0, 5.7.0,
5.7.8, 5.7.9, 5.7.11, 4,7.12, 5.7.12, and x.5.6.

| must be registered with IANA under the IETF Consensus method.
| (Specifically, new assignments are made via RFCs approved by
| the IESG.)

The IESG has approved RFCs without Last Call and without IETF
consensus, for examples see RFCs 4405, 4406, 4407, and 4408.
(4408 doesn't invent a status code, but it has a 3464 reference)

Please add the sources to your enumeration (e.g. RFC 2554bis)...

| X.7.14 Trust relationship required  The submission server requires
|    a configured trust relationship with a third-party server in
|    order to access the message content.  This value replaces the
|    prior use of X.7.8 for this error condition.
| X.7.15 Authentication credentials invalid  Authentication failed
|    due to invalid or insufficient authentication credentials.
|    This value replaces the prioruse of X.7.8 for this error
|    condition.

...or in these cases the source [RFC XXXX], i.e. your draft.

| 5.1.  Normative References
[...]

Please add 2554bis here.

Frank


<Prev in Thread] Current Thread [Next in Thread>