Subject: [apps-discuss] Question about mailto URI

From: Stephan Bosch <[email-masked]>
Date: Sun, 14 Feb 2016 02:02:50 +0100

Hi,

I have a question about the mailto URI specified in RFC 6068. The following syntax is specified for header fields:

hfields      = "?" hfield *( "&" hfield )
hfield       = hfname "=" hfvalue
hfname       = *qchar
hfvalue      = *qchar

This syntax allows an empty header field name, whereas RFC 5322 specifies the following:

optional-field  =   field-name ":" unstructured CRLF
field-name      =   1*ftext
ftext           =   %d33-57 / %d59-126 

This doesn't allow empty header field names, which makes sense to me.

Is there a reason to allow an empty header field name for the mailto URI, or am I just looking at something that warrants an erratum for the RFC?

Regards,

Stephan.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 19 Feb 2016 18:41:48 +0000

Hi Stephan,

> Is there a reason to allow an empty header field name for the mailto URI, or am I just looking at something that warrants an erratum for the RFC?
I don't know of any reason to allow for empty header field names. 
Although at this point implementations should just ignore empty fields.

Best Regards,
Alexey

---

From: Martin J. Dürst <[email-masked]>
Date: Sat, 20 Feb 2016 13:05:05 +0900

Hello Stephan,

Sorry for the delay of my answer.

On 2016/02/20 03:41, Alexey Melnikov wrote:
>> I have a question about the mailto URI specified in RFC 6068. The
>> following syntax is specified for header fields:
>>
>> This syntax allows an empty header field name,

I have been able to trace this back to 
https://tools.ietf.org/html/rfc2368, where the rules in question are

      headers    =  "?" header *( "&" header )
      header     =  hname "=" hvalue
      hname      =  *urlc
      hvalue     =  *urlc

>> whereas RFC 5322
>> specifies the following:

It makes a lot of sense to me, too.

>> Is there a reason to allow an empty header field name for the mailto
>> URI, or am I just looking at something that warrants an erratum for
>> the RFC?

I'm thinking about producing an update to RFC 6068 once it is possible 
to use non-ASCII characters in RFCs, which should be "soon". At that 
point, we should re-check this issue.

Looking at RFC 6068, there's already quite some text at the end of 
Section 3 and in Section 4 that makes it clear that MUAs and the like 
have to be careful to not just put all the header fields into an email 
message as-is. This should cover empty header field names, too, but it 
might be a good idea to point this out more specifically in an update.

Regards,   Martin.