Subject: Re: [Jmap] Decoding of unknown headers

From: Alexey Melnikov <[email-masked]>
Date: Fri, 22 Dec 2017 14:48:41 +0000

On 22/12/2017 14:43, [email-masked] wrote:

> While decoding the headers. If the FROM,TO,CC headers are are 
> containing ACE encoding or punycode or utf8 local part, how its 
> expected to be returned.
No changes to the local part of email addresses must be done by JMAP server.

If we want to support EAI email, we need to say how this is handled by 
JMAP servers. Decoding punycode in domain part of email addresses is Ok, 
but shouldn't be required.

> On 22-Dec-2017 at 18:47:50
> Alexey Melnikov [email-masked]' wrote:
> *From:* Alexey Melnikov <[email-masked]>
> *To:* Josef 'Jeff' Sipek <[email-masked]>, Neil Jenkins 
> <[email-masked]>
> *Cc:* IETF JMAP Mailing List <[email-masked]>
> *Subject:* [Jmap] Decoding of unknown headers
> *Date:* 22 December 2017 at 18:47:50 IST
> On 07/12/2017 22:32, Josef 'Jeff' Sipek wrote:
>
>> On Wed, Nov 29, 2017 at 14:58:57 +1100, Neil Jenkins wrote:
>>> Some thoughts:
>>>
>>> We currently have the following properties which represent parsed forms
>>> of headers: sender, from, to, cc, bcc, replyTo, subject, date. You can
>>> also request (decoded but otherwise unparsed) headers using the
>>> "headers" property. Perhaps what we should do is remove the special 
>>> case
>>> properties and instead have the client request header names + how to
>>> process each one (raw base64, decoded, parsed as name/email list, 
>>> parsed
>>> as date; may be extensible in the future). The syntax would need to be
>>> usable for setMessages too in some way.
>>> The other thing to think about is what to do when you have multiple
>>> headers of the same name; maybe you can explicitly request to receive
>>> all (as an array), otherwise you get the last one of that name.
>> I like this idea, but I'd say always return all. The extra two chars 
>> of JSON
>> won't make much of a difference.
>
> Always returning all is fine. We just need to have examples in the draft
> showing multiple values, so that people don't forget to write code to
> support this.
>
>
> _______________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap
> .

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 22 Dec 2017 15:30:36 +0000

The EAI RFCs do not specify that punycode is to be handled in any 
particular way, so it would be inappropriate for the JMAP document to 
specify more.

BTW, I know that several programs ignore punycode when 
replying, recognising the user's own address and/or expanding aliases, 
so sending punycode in header fieldd seems unwise.

Arnt