Re: [Extra] New Version Notification for draft-bosch-sieve-eai-01.txt

[Ned Freed <[e-mail]>]

I'm afraid this document has a lot of probems, some of which may not be easy to
resolve.

The biggest problem by far is that the idea of invoking an extension in order to
be able to process an EAI message is intrinsicly nonsensical: A message
presented to the Sieve interpreter is either an EAI message or it's not, and
there's nothing the Sieve interpreter or Sieve author can do to change that. (It
may not even know if a given message was intended to be in EAI format - there's
no reliable marker for this.)

And now things start to get sticky: There's no telling what will happen if you
feed an EAI message into a Sieve implementation that's not itself EAI aware.
Will it simply process the UTF-8 it finds by leaving it alone (likely)? Or will
it treat the UTF-8 it finds in headers as illegal - whatever that means? Will it
know that message/global contains a message, and if so, will it be able to look
inside of an encoded message/global (probably not)?

The ineluctable conclusion here is that an email system that supports both EAI
and Sieve in a compliant way MUST support EAI in Sieve. This is a compliance
matter, plain and simple, and cannot be handled as an extension. So the first
task of this document needs to be to define what this form of compliance means.
It definitely includes saying that the header and address tests must allow for
unencoded UTF-8, proper handling of message/global, and probably a bunch of
other stuff.

But now things get even stickier: A-labels. EAI extends the message format to
allow, among other things, U-Labels in domains, but AFAIK doesn't explicitly say
that A-Labels cannot be used. (Except in the case of domains in trace fields,
and as a recent discussion has shown, it appears this requirement is being
widely ignored.)

Domains appear in a lot more header fields than addresses, and it would be
asking a lot of a Sieve implementation to know how to parse them all and convert
A-labels to U-labels. FWIW, I think the right answer is to only perform the
conversion in the address test, but I could be persuaded  otherwise.

Redirect, vacation, notify, and any other action that sends a message are where
an smtputf8, as opposed to an eai, Sieve extension makes sense. And note that
all of these actions can send an EAI even if the original message wasn't EAI.

A careful review of every Sieve extension with an eye to how it interacts
with EAI needs to be done, but that should be deferred until we're settled
on the overall approach.

Finally, I note that there's some odd language in the current document
about not interpreting encoded-words in EAI messages. This makes no sense
to me as messsages are often Frankensteinian in origin and can easily
end up with a mix of UTF-8 and encoded-words.

				Ned

> Hi,

> This is just a refresh of the document submission. Apart from my address
> information, nothing changed.

> -------- Forwarded Message --------

> A new version of I-D, draft-bosch-sieve-eai-01.txt
> has been successfully submitted by Stephan Bosch and posted to the
> IETF repository.

> Name:		draft-bosch-sieve-eai
> Revision:	01
> Title:		Sieve: Internationalized Email
> Document date:	2021-05-25
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/archive/id/draft-bosch-sieve-eai-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-bosch-sieve-eai/
> Html:
> https://www.ietf.org/archive/id/draft-bosch-sieve-eai-01.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-bosch-sieve-eai
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-bosch-sieve-eai-01

> Abstract:
>     This document defines an extension to the Sieve language called "eai"
>     which adds full support for internationalized email.

 


> The IETF Secretariat


> _______________________________________________
> Extra mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/extra