Re: Fwd: New Version Notification for draft-crocker-email-deliveredto-05.txt

On 8/15/2021 2:51 PM, Viktor Dukhovni wrote:
> On Sun, Aug 15, 2021 at 02:18:46PM -0700, Dave Crocker wrote:
> 
>>> The above shows a profound unwillingness to look beyond the apparent
>>> syntax to the semantics committed to by the MTAs that are using this
>>> header.  The extant implementations of "Delivered-To" make no promise
>>> to record anything recognisable to any party other than the MTA.
>>
>> Documenting existing practice means documenting practice that actually
>> exists.
> 
> When documenting *interfaces*, we do not document implementation

This is a protocol/format specification, not an interface specification. 
  It documents what goes over the wire, as IETF typically does.


> artefacts of what the interface happens to be doing.  We document
> the interface contract, i.e. what the interface is *expected* to do.

That isn't what IETF specifications do.



> When I say that "Delivered-To" is an opaque token private to the MTA,

That's nice, but does not represent the observable existing behavior. 
And what /you/ mean is less of an issue that was actual existing 
practice is.


> this is not an empirical statement.  It is a statement of fact about the
> contract between Postfix and the rest of the world.

There is behavior, not a contract.


> Other than loop detection, and forensic evidence trails, what else
> motivates the draft?

It's already stated in the draft.


>> So I don't really know what you mean about looking to the semantics,
>> since the document supports the semantics of current practice.
> 
> What is the nature experiment?  If you're documenting current practice,
> how can the draft be "Experimental"?

Victor, it is not helpful for you to keep asking a question or 
challenging a point that has already been repeatedly answered.



>> Since you disagree, please be specific. What semantics are there, in
>> current practice, that are not supported by the current draft?
> 
> What is the motivation for producting the draft?  What problem are you
> actually tryign to solve?

Read the draft.

It would also be nice for you to answer the questions /I/ am asking /you/.




>>> It is not acceptable to violate the interface *contract* and saddle the
>>
>> That's nicely forceful and legalistic language, but there isn't a
>> contract.  There is a goal of being compatible with existing practice,
>> which this draft is.
> 
> If it binds the MTA to produce tokens that an MUA will be able to
> parse and act on, then it is NOT compatible with existing practice.

Ahh.  So you mean the specification should specify behaviors.  It does that.


>>> "Delivered-To" header with new semantics, whereby the recorded address
>>> is anything other than an opaque token.
>>
>> Sorry but the existing practice is the syntax of an email address and,
>> often, actually the email transport recipient address.
> 
> No existing practice is the interface supported by the MTA, and the
> MTA's freedom to make any and all changes that don't violate that
> interface contract.

So there is already a written 'contract' -- presumably you mean 
'specification' that all existing systems conform to?

Absent that, there is no contract.  There is only existing practice. 
The document seeks to specify that practice, but in a larger context of 
utility.

The document contains technical details.  Other than the abstractions of 
contract and token, you have yet to point at technical details in the 
draft that are not correct.


>> Claiming otherwise might satisfy one's sense of abstraction, but goes
>> beyond existing practice.
> 
> Surprisingly, you're conflating implementation with specification.

Nope.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net