Re: [EAI] I-D Action:draft-ietf-eai-mailto-00.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 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.  Maybe putting this all on hold until
2822upd is no moving target, which could be really soon.

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

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.

| 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



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.