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

--On Tuesday, August 17, 2021 09:32 -0700 "Murray S. Kucherawy"
<[email protected]> wrote:

> On Tue, Aug 17, 2021 at 7:10 AM John C Klensin
> <[email protected]> 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