Re: [EAI] I-D Action:draft-ietf-eai-mailto-00.txt

[Martin Duerst <duerst at it.aoyama.ac.jp>]

At 12:45 08/02/19, Frank Ellermann wrote:
>> An update to the mailto URI scheme for Email Address Internationalization
>
>Oops, I thought the idea was to finish mailto-bis *before*
>tackling mailto-eai.

Well, yes in theory, but in practice, it makes quite a bit
of sense to have these activities overlap. See below for
an example.

>Maybe putting this all on hold until
>2822upd is no moving target, which could be really soon.

We don't need to put it on hold. We may want to wait with
finalization to make sure we are in sync with 2822upd, but
we still can use the time to move ahead and tease out issues.

>The draft says that mailto-eai is based on RFCXXXX, that's
>mailto-bis.  Apparently RFCYYYY is the utf8headers draft.

Correct.

>Where RFCXXXX mailto-bis uses <addr-spec> mailto-eai needs
>RFCYYYY <utf8-addr-spec>, not the <mailbox> like RFC 2368:
>
>Replacing the x822 <mailbox> by the x821 <Mailbox>, or in
>other words x822 <addr-spec>, is one the mailto-bis points,
>no comments (etc.) in mailto-eai or mailto-bis, as already
>noted by John.

I just submitted another version of draft-duerst-mailto-bis,
and while working on the edits, had the chance to do some
"archaeology". The change from <mailbox> to <addr-spec>
happened in draft-duerst-mailto-bis-01.txt, after a not-
necessarily conclusive discussion involving (among others)
Bruce Lilly, Paul Hofmann, John Cowan, Larry, and Frank.
It may be Larry who made the actual edit, but it may have
been me.

When drafting mailto-eai, I was looking at the utf8headers
draft and decided that in order to get a syntax definition
for the <internationalized <fallback>> construct, the best
thing to pick was <mailbox>.

Obviously, while in email header fields, the syntax
<internationalized <fallback>> isn't a big issue, in
mailto URIs, it doesn't look pretty at all.

The first alternative might be to use
   internationalized <fallback>
or some such, but that might not fly because it would
just be interpreted as
   display_name <email_address>
by most current mailto: implementations who may, either
by design or more probably by accident, still implement
mailto: according to RFC 2368.

Of course, we could define things so that
   foo <bar>
gets parsed as
   display_name <email_address>
(backwards compatible behavior for RFC 2396) if foo is
ASCII-only, and
   internationalized <fallback>
if foo (the LHS side of foo?) contains non-ASCII characters,
but we should carefully think about the consequences this has
for implementations.

Any further comments, in particular on this major point,
greatly appreciated.


Regards,    Martin.


>| to = [ mailbox *("%2C" mailbox ) ]  
>
>Compare <http://article.gmane.org/gmane.ietf.rfc822/12049>
>
>I'm not sure about the necessity of "%2C" instead of ","
>here.  Plus a few other issues like reserving "?" in the
>query part, or reserving ";" before the query part (or at
>all, see the original mailto-bis review at the given link).
>
>mailto-bis got rid of <urlc> because it's not more defined
>in STD 66.  Apparently mailto-eai is based on an obsolete
>mailto-bis-00 or mailto-bis-01. 
>
><urlc> was fixed (eliminated) in mailto-bis-02, the current
>version is mailto-bis-04.
>
>| Please note that if the left-hand side of the mail address
>| contains non-ASCII characters, the less-than and 
>| greater-than sign (anglebrackets, escaped as %3C and %3E)
>| are mandatory.
>
>That is a consequence of using RFCYYYY <mailbox>, or maybe
>RFCYYYY <angle-addr>  BTW, there is an ABNF bug in RFCYYYY:
>
>| angle-addr =/ [CFWS] "<" utf8-addr-spec [ alt-address ] ">" [CFWS] /
>|               obs-angle-addr
>
>Please strike the "/" in "=/" (found in eai-utf8headers-09).
>
>For the purpose of mailto-eai I think we can get rid of the
>angle brackets at this level.  RFC 2368 and mailto-bis also
>don't don't have angle brackets.
>
>mailto-eai only needs the stuff *within* the angle brackets,
>that is  utf8-addr-spec [ alt-address ]  Maybe using its own
>name for this construct:
>
>  utf8-addr = utf-8-addr-spec [ alt-address ]
>
>Importing utf8-addr-spec and alt-address "as is" from RFCYYYY.
>
>Note that there still are angle brackets at the level of the
>alt-address.  And there's another bug in RFCYYYY, 1*FWS is
>incorrect, how often did I aready report this trivial bug ?
>
>THERE IS NO SUCH THING AS 1*FWS, JUST FWS DOES WHAT YOU WANT.
>
>Back to mailto-eai:
>
>| Please note that at least a space is needed before the 
>| "alt-address", and that such a space also has to be 
>| percent-encoded.
>
>Yes.  I wonder if mailto-eai could simplify it into "one and
>only one percent-encode space".  The FWS business is about
>folding long header fields (once, not 1*FWS multiple times).
>
>mailto-eai only needs a separator, nothing more elaborated,
>and soon net-utf8 will start to finish off HTAB everywhere.
>
>One %20 is IMO bad enough for mailto-eai, no percent-encoded
>FWS please.
>
>Maybe mailto-eai should get an IRI example, using hex. NCRs
>to emulate UTF-8 in an US-ASCII draft.  Ideally it should
>also have an IRI example for a legacy charset like KOI8-R,
>but I fear that's too confusing in an US-ASCII draft or RFC.
>
> Frank
>
>_______________________________________________
>IMA mailing list
>IMA at ietf.org
>http://www.ietf.org/mailman/listinfo/ima


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp     

_______________________________________________
IMA mailing list
IMA at ietf.org
http://www.ietf.org/mailman/listinfo/ima