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

--On Monday, August 16, 2021 23:03 -0700 "Murray S. Kucherawy"
<[email protected]> wrote:

> On Thu, Aug 5, 2021 at 9:47 AM Dave Crocker <[email protected]>
> wrote:
> 
>> There are a number of possible reasons for seeking
>> Experimental status to an RFC:
>> 
>>       1. The technology is defines is not yet understood well
>>       enough and there are concerns that its functionality,
>> reliability, or the like might not behave as intended
>> 
>>       2. The proposed use of the technology might go beyond
>>       established practice and the expanded use might need
>> vetting
>> 
>>       3. The technology might not scale adequately for
>>       Internet use
>> 
>>       4. The market might not be sufficiently interested in
>>       the technology to choose to use it
>> 
>>       5. The documentation of the technology might need wider
>>       review and comment
>> 
>> The current draft probably qualifies under more than one of
>> these.
>> 
> 
> I suggest considering BCP 9, which defines "Experimental" thus:
> 
>    The "Experimental" designation typically denotes a
> specification that    is part of some research or development
> effort.  Such a specification    is published for the general
> information of the Internet technical    community and as an
> archival record of the work, subject only to    editorial
> considerations and to verification that there has been
> adequate coordination with the standards process [...]
> 
> (Then again, BCP 9 has been updated over a dozen times, and I
> may have missed an extended definition in one of those.)
> 
> I can see why people might find it odd to claim that something
> dating back to the 1990s, as this draft says, is being
> categorized as an R&D effort today.
> 
> Perhaps the Introduction might be amended to explain this
> perceived discrepancy?

Murray,

A slightly different point of view.  While something called
"Delivered-to:" has been widely deployed, it appears from the
discussions of the last months that there is less than complete
agreement about semantics, intended purpose, and perhaps (I'm
not sure) even the syntax of the header field.  The draft
acknowledges those differences and has become more clear and
specific as we have moved along (thanks, Dave).  However, making
the definition and statement of intent has inevitably moved it
much closer to some implementations and conceptual models and
further from others.  

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.

Another experimental bit is indirectly called out in the
document.  The "for" clause of the Received: header field goes
back to 821/822 or further.  In recent years, its use has been
discouraged, even though not formally deprecated, for reasons
very similar to those covered by the Security Considerations
section of the current document.   The description in Section 2
("However the clause is not used reliably") seem quite accurate.
But, to at least some extent, that means anther part of the
experiment is "why will this succeed when 'for' has fallen into
disuse or failed?" and/or "given that the objection to 'for' was
precisely the disclosures and address transformations discussed
in Section 6, how is 'Delivered-to:' better?".

The document mentions those issues, even if sometimes obliquely.
While my perspective may be a bit different, I don't think I am
saying anything new.  However, it seems much more clear now than
it was early in the year --from both the evolution of the
document and list discussions-- that the document is not
completely consistent with existing practices, no matter how
undocumented and informal.  With apologies for the lateness of
this suggestion (it did not occur to me until quite recently),
that suggests to me that, if this is an experiment, it would be
better to come up with a new name for the header field rather
than reusing one that is already in use.  That would make it
easier for existing implementations to be brought into
conformance because if would raise no issues about which
definition is in use (issues that would affect both contemporary
receivers and loop-detectors) and would make the experimental
issues much more clear.  

best,
   john

> 
> -MSK