ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Fwd: New Version Notification for draft-crocker-email-deliveredto-05.txt

2021-08-15 23:05:41
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

_______________________________________________
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>