Subject: Re: [Jmap] Address Groups - proposals

From: Neil Jenkins <[email-masked]>
Date: Mon, 06 Aug 2018 02:30:37 -0400

On Tue, 17 Jul 2018, at 6:43 AM, Ricardo Signes wrote:
> I would suggest that :asAddresses does what Bron called "flat no groups", and
> that :asGroupedAddresses does "nested full".

This reasoning seems sound to me. I'm going to go with this unless anyone provides a strong objection.

Neil.

---

From: Mads Hjorth <[email-masked]>
Date: Mon, 6 Aug 2018 08:10:54 +0000

All though Mailbox groups are rarely seen, there are valid use cases for them. We are looking at one, where a public authority sends notification of road work. The address the mail to: Citizens living along road X, and BCC all the email adresses of those.

In my understanding the current proposal will result in the following:

Calling asAddresses (Flat no groups) will result in

[]

and asGroupAddresses (Nested Full) will result in

{ group: "Citizens living along road X", addresses: [] }

So when a non-domain experts call asAddresses they would have to call the asGroup version to find out if the empty list means no adresses or just no non-group adresses?

Or do I misread something?

/madsh

On 16 Jul 2018, at 22.37, Ricardo Signes <[email-masked]<mailto:[email-masked]>> wrote:

* Bron Gondwana <[email-masked]<mailto:[email-masked]>> [2018-07-16T16:12:49]
There's been a bunch of discussion both here, in the meeting today, and
on Jabber.  I figured I'd give them all catchy names and write up how
they'd look for this theoretical header line:

Thanks for this!

My thinking here is:

1.  I love that JMAP makes working with email so approachable for non-domain
   experts.  It's an easy to understand API, and you can get to work by using
   it in a beginner's way before progressing, if ever, to more complex modes
   of operation.  I want to build on this property of JMAP when possible.

2.  I love that even for advanced operation, it is almost never necessary to
   resort to fetching the message/rfc822 blob.  Most data is available in raw
   or differently-processed forms.  Even experts shouldn't have to resort to
   blob processing most of the time.

Mailbox groups are worth making available because of reason #2.  Experts
shouldn't have to get the raw header, encoded-warts and all, and work out the
header structure.

On the other hand, mailbox groups are rarely seen and even more rarely worth
noting.  The casual user can, I assert, pay them no mind.  Groups should not
complicate the life of the casual user.

Providing a flat list is nice for the casual user, but if the flat list
contains weird-o non-address sentinel values, *it's no longer a flat list*.
It's a deeper structure that has been serialized into a flat list.  I think
it's worse for both sets of users: it's an unnatural expression of the
structured data that an advanced user might want, and it's an unnatural
expression of the simple data that a beginner might want.

(I also think that in the simple case, any entry with a null email is not
great.)

This is why I think we're best off providing two distinct forms:  one to
provide the simplest form for 99.9% of input and for casual users, and one with
an appropriate data structure for those who care about group structure.

I think that trying to be understandable is a good goal, but using a
pre-existing IMAP convention that will be understandable to already-minted
experts in IMAP is far less compelling to me than to simply be understandable
by using a self-explanatory data structure.

--
rjbs

_______________________________________________
Jmap mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jmap

---

From: Neil Jenkins <[email-masked]>
Date: Mon, 06 Aug 2018 18:21:46 +1000

On Mon, 6 Aug 2018, at 6:10 PM, Mads Hjorth wrote:
> So when a non-domain experts call *asAddresses *they would have to
> call the asGroup version to find out if the empty list means no
> addresses or just no non-group addresses?
In both cases there are no addresses. It's just that there is a group
name you could display if you want to handle the more complicated
version. Simply displaying "Undisclosed recipients" when there are no
addresses in either To or CC is probably sufficient for most clients in
this situation, and for those that want to do more, the
asGroupedAddresses format lets them handle that.
Neil.

---

From: Neil Jhaveri <[email-masked]>
Date: Tue, 7 Aug 2018 10:43:20 -0700

I also will voice my support behind Ricardo’s proposal to just provide 2
forms. I think it’s a good trade-off.

On Sun, Aug 5, 2018 at 11:30 PM Neil Jenkins <[email-masked]> wrote:

> [email-masked]