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.