Re: (Re: EAI WG status and rechartering) -- mailto bis

Hello Joseph,

On 2009/11/27 1:48, Joseph Yee wrote:
> Hi Martin,
>
> I read the latest mailto-bis (07). Section 2.4 and 2.5 are great.

These are just point 4 and 5 in a numbered list within Section 2, but 
thanks for your review and comments, anyway.

> In the paragraph right after section 2.5, it mentions the pct-encoding
> for <hfname> and <hfvalue>. My own interpretation had it sounds like
> allowing <hfname> to be pct-encoded. Since current and proposed message
> header definition do not allow non ASCII characters, wouldn't that be
> easier to limit <hfname> to ASCII only? That would make <hfname> be case
> insensitive easier to manage too.

Okay, so you are proposing to change the grammar from:

       hfname      = *qchar

(with qchar being unreserved / pct-encoded / some-delims) to:

       hfname      = unreserved

On the face of it, that may seem okay. But looking at things in detail, 
it isn't. Optional header field names, as defined in RFC 5322 (see 
http://tools.ietf.org/html/rfc5322#section-3.6.8) can include any 
printable ASCII character except ":". So for whatever reason, and 
however unlikely, there may be a header field named "#browns" (an 
abbreviation for "hashbrowns"), where the "#" would need escaping in a 
mailto: URI. This would lead to an example such as:

mailto:frypan <at> kitchen.home?%23browns=diced-with-bacon

Which would translate to a mail containing:

To: frypan <at> kitchen.hom
#browns: diced-with-bacon

So even if this example is quite silly, we can essentially not remove 
pct-encoded from the production. This means that software interpreting 
the mailto: URI has to reverse the %-escaping on hfnames, anyway.

Do you think we need such an example? I hope not, but if you think it 
would help, I'd also appreciate ideas for a somewhat better example.

> I noticed that section 4 would stop
> non ASCII in <hfname>, but wonder if it's good to restrict it in mailto
> IRI.

Yes, you are correct, section 4 would essentially stop non-ASCII as well 
as most ASCII, too.

Regards,    Martin.

--

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst <at> it.aoyama.ac.jp