ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto)

2021-08-17 12:19:55


--On Tuesday, August 17, 2021 09:32 -0700 "Murray S. Kucherawy"
<superuser(_at_)gmail(_dot_)com> wrote:

On Tue, Aug 17, 2021 at 7:10 AM John C Klensin
<john-ietf(_at_)jck(_dot_)com> wrote:

With one qualification, it seems to me that it would be a
legitimate experiment, well within the intent of BCP 9, to
create a definition this, or more, precise and then see
whether existing implementations that use this field or ones
that appear (at least superficially) similar to it evolve to
conform.  That seems consistent with several of the bullet
points in Section 8 of the document as well.    The
qualification is that, while it would be interesting to find
out if this were the exception, we have considerable
experience that, if a feature is implemented and used by
implementations with particular syntax and semantics, the
odds of those implementations making changes that might
disrupt existing uses and operations and introduce confusion
as to whether the "old" or "new" definitions were in use is
vanishingly small.   Nonetheless, it would be a real
experiment and it is not clear to me whether the document
needs additional work to explain that.
[...]


Fair enough.  I don't necessarily object to the use of
Experimental, but I think it appropriate to explain its
curious use in the context of a technique that has existed in
some form for quite a while now.   I take the BCP 9 definition
to mean "let's try this" more so than "let's write down this
thing we've been 'trying' in some form or another since the
'90s". Anyone reviewing this later (the ISE, the IESG during
its conflict review, anyone the ISE asks to look at it, etc.)
is also liable to trip over this, so a sentence or two
explaining the dissonance would probably help to smooth its
handling.

Murray,

I certainly agree that there is some apparent dissonance, that
the use is curious, and that more explanation would be desirable
and possibly a requirement.  
 
However, after thinking more about the comments from Victor
today and reviewing more of the comments on list, I think there
is another serious obstacle (or maybe just a choice).  IMO
(now), if it is an Experiment, it must either:

* carefully explain its relationship to existing implementations
that probably won't change, address the question of semantics
that Victor and others have raised (either what they are or why
they are unimportant), and make what it would mean to be
interoperable clear.  Probably that includes some hints about
how a particular MDA or other user of the field can distinguish
the new/Experimental version and definition from the historical
ones. The interoperability issue is no less important if
"private" is part of the story than if it is not although the
"private" description would probably be much shorter.

   --or--

* treat this a something new, with a new header field name, and
proceed to describe that new thing.  Presumably that should
include a discussion of why it is different and implementations
should provide it instead or in in addition to Delivered-to,
Envelope-to, Received...for, and anything else that is
considered particularly relevant, but we have traditionally cut
Experimental documents some slack and it would be, IMO, entirely
plausible for an Experimental description of a header field with
a new name to carefully describe figuring that out as part of
the experiment.  A new field name would bring a bonus: we could
consider whether a registered token at the beginning of the
field that identified the relevant MDA (or whatever) would be
helpful in efficiently eliminating any possible "is this really
mine" confusion.

Otherwise, it seems likely to me (and I gather certain to
Victor) that an "Experiment" would be generally ignored (in
which case, what would the point be) or that it would introduce
confusion with existing practice (in which case there should be
far stronger reasons to not publish than procedural definitions).

Where Victor (and others) and I may disagree is whether the
first of those options is even possible.  I think it probably
is, but I am not strongly convinced (and "probably possible"
does not translated to "necessarily a good idea").

best,
   john

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

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