Subject: Re: [Jmap] Decoding of unknown headers

From: Josef 'Jeff' Sipek <[email-masked]>
Date: Thu, 7 Dec 2017 17:32:09 -0500

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.

> One possible syntax:
> 
> "getMessages", {
>   ...
>   "properties": [
>     "headers.received:decoded+all"
>     "headers.from:raw",
>     "headers.to:emails",
>     "headers.subject:decoded",
>     "headers.date:date"

The only downside I can think of vs. the special cased properties is that
the properties implied the correct decoding/parsing.  For example, the
"date" property was always decoded at a date but with the scheme this email
proposes the client has to explicitly ask for :date format.  I think it is
still worth it to explore this header centric approach.  (This gets us back
on the message representation discussion.)

>   ],
> }
> 
> and then the Message object would look something like:
> 
...
> 
> This gives a lot of flexibility to clients, but is a bit verbose.

I don't think it is that bad.  The client will likely always want to request
the same headers with the same encoding, so it shouldn't increase code
complexity in a significant way.  The repeateded "type" and "value" strings
shouldn't take up that much bandwidth.  (And if bandwidth is really that
tight that the repetition would matter, the HTTP server will compress the
responses anyway.)

...
> You could also default to type "decoded" if no other processing explicitly
> requested, and possibly even drop the {type, value} wrapper for headers
> with the default decoding.

Defaulting to "decoded" sounds fine.

One note about using "decoded" - it sounds a bit generic.  Decoded *how*?  I
realize it is likely RFC 2047, but I'm not sure it is obvious from the
proposed name.  Would "text" make more sense?  Since we are dealing with
JSON, the encoding sent in the response has to be UTF8.

What happens if the server cannot decode a header?  (The Date or To header
is malformed, or the header contains something that's a bad attempt at RFC
2047, and so on.)

If the client requests decoding "X", what does the server have to do?  MUST
the server respond with "X"?  Or MAY the server respond with "Y"?  E.g., if
I ask the server for headers.subject:date, can the server respond with a
value as if I asked for headers.subject:text?

Jeff.

-- 
I'm somewhere between geek and normal.
		- Linus Torvalds

---

From: Stan Kalisch <[email-masked]>
Date: Thu, 7 Dec 2017 22:05:45 -0500

>> On Dec 7, 2017, at 5:32 PM, Josef 'Jeff' Sipek <[email-masked]> wrote:
>> 

I agree that always return all really is the more desirable behavior here.

Thanks,
Stan

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 22 Dec 2017 13:17:50 +0000

> 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.