Subject: [Extra] Uploaded new draft renaming uniqueid -> objectid

From: Bron Gondwana <[email-masked]>
Date: Fri, 20 Apr 2018 17:57:23 +1000

I've just uploaded a new version of the uniqueid draft.  I renamed
everything to OBJECTID (including the draft name) and normalised the
descriptions of things.
Everything is wrapped with tagged-ext as per RFC4466 now, and I've
inserted tons of examples and a complete (I think!) ABNF.
I would love to have some reviews on this.  I've implemented it inside
Cyrus IMAP master as well, and we've started using the MAILBOXID fetch
item in production at FastMail already.
Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: "Chris Newman" <[email-masked]>
Date: Sun, 22 Apr 2018 13:48:29 -0700

>   This document extends the CREATE command to have the response code
>   MAILBOXID on successful mailbox creation.

This needs to be registered in IANA's IMAP Response Code registry (per 
RFC 5530).

>   The server MAY us content detection to assign the same EMAILID upon

us => use
Also, the word "duplicate" might be more informative than the word 
"content" here.

>   The THREADID data item is an objectid which uniquely identifies as
>   set of messages which the server believes are related in some way.
   as => a

I think "which the server believes are related in some way" is vague. 
Perhaps try this instead: "that the server believes should be grouped 
together when presented to the end-user".

It would be helpful to add an informative reference to RFC 5256 as an 
example of algorithms to determine which messages are in a thread. We 
don't want to mandate one of those algorithms, but it's a reasonable 
choice for an implementer who would otherwise be unsure of what to do.

> Message-ID: <[email-masked]>

You should probably use reserved domains like "example.com" here (RFC 
2606).

The ABNF is technically incorrect because a ";" is "comment to 
end-of-line" syntax and the line wrapping breaks that model.

There's been a discussion of the imprecision of case-sensitive vs. 
case-insensitive strings on one of the lists. One thing you could do is 
reference RFC 7405, and replace the paragraph about 
case-sensitive/case-insensitive with explicit ABNF such as:

    capability =/ %i"OBJECTID"

    fetch-att =/ %i"EMAILID" / %i"THREADID"
...

Editor's choice if you want to do that; just making a suggestion based 
on the recent discussion.

>    unique, but they it is only required to be unique within a single

delete "they". I suggest making that "unique within messages offered by 
a single IMAP client connection to a given IMAP server domain name." 
NOTE: allowing a proxy to combine multiple independent "servers" into a 
view with conflicting object ids would be bad. They have to be 
server-unique from the client's perspective so a server-side IMAP proxy 
SHOULD NOT advertise this extension if multiple back-ends can use the 
same id for two different objects.

> 8.3.  Ideas for implementing object identifiers

My editorial preference is to put non-normative suggestions in an 
Appendix; that's also common in other RFCs.

>   o  Digest of (MailboxName/UIDVALIDITY/UID) - is not kept when 
> copying
>      messages, but is guaranteed unique and doesn't require storage.

Another suggestion is digest of MAILBOXID/UIDVALIDITY/UID (for servers 
that store a MAILBOXID but not EMAILID).

>  Security Considerations

emailed and threadid need to have a collision-resistant property, so use 
of MD5 or SHA1 of the message content is not sufficient.

		- Chris

> _______________________________________________
> Extra mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=qqTGVtPGH14EDAfy2rHX9cabU-5O66pevmiTmyTOj-s&s=1A_gHWeYuC5cJLMmZJWA2QHADDGIXRgwoYYu50lbIYw&e=

---

From: Bron Gondwana <[email-masked]>
Date: Mon, 23 Apr 2018 16:05:22 +1000

Thanks for the detailed feedback!  I'll push an update soon.

Cheers,

Bron.

> RFC 5530).>> The server MAY us content detection to assign the same EMAILID upon> us => use
>  "content" here.>> The THREADID data item is an objectid which uniquely identifies as
>>  set of messages which the server believes are related in some way.> as => a

> together when presented to the end-user".> It would be helpful to add an informative reference to RFC 5256 as an
> choice for an implementer who would otherwise be unsure of what to do.>> Message-ID: <[email-masked]>

> You should probably use reserved domains like "example.com" here
> (RFC 2606).> The ABNF is technically incorrect because a ";" is "comment to end-of-
> line" syntax and the line wrapping breaks that model.> There's been a discussion of the imprecision of case-sensitive vs. case-
> insensitive strings on one of the lists. One thing you could do is
> reference RFC 7405, and replace the paragraph about case-sensitive/case-
> insensitive with explicit ABNF such as:> capability =/ %i"OBJECTID"

> on the recent discussion.>> unique, but they it is only required to be unique within a single

> delete "they". I suggest making that "unique within messages offered
> by a single IMAP client connection to a given IMAP server domain
> name." NOTE: allowing a proxy to combine multiple independent
> "servers" into a view with conflicting object ids would be bad. They
> have to be server-unique from the client's perspective so a server-
> side IMAP proxy SHOULD NOT advertise this extension if multiple back-
> ends can use the same id for two different objects.>> 8.3.  Ideas for implementing object identifiers

> Appendix; that's also common in other RFCs.>> o  Digest of (MailboxName/UIDVALIDITY/UID) - is not kept when copying>>  messages, but is guaranteed unique and doesn't require storage.

> that store a MAILBOXID but not EMAILID).>> Security Considerations

> emailed and threadid need to have a collision-resistant property, so
> use of MD5 or SHA1 of the message content is not sufficient.> - Chris

>> descriptions of things.>> 
>> inserted tons of examples and a complete (I think!) ABNF.>> 
>> I would love to have some reviews on this.  I've implemented it
>> inside Cyrus IMAP master as well, and we've started using the
>> MAILBOXID fetch item in production at FastMail already.>> 
>> Cheers,
>> 
>> Bron.
>> 
>> --
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=qqTGVtPGH14EDAfy2rHX9cabU-5O66pevmiTmyTOj-s&s=1A_gHWeYuC5cJLMmZJWA2QHADDGIXRgwoYYu50lbIYw&e=> _________________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 24 Apr 2018 12:30:13 +1000

> This needs to be registered in IANA's IMAP Response Code registry (per
Thanks, updated.

>> The server MAY us content detection to assign the same EMAILID upon> us => use
Rewritten

> choice for an implementer who would otherwise be unsure of what to do.
Entirely rewritten, with the informative reference as suggested.

> (RFC 2606).
Done - example.com and example.org.

> The ABNF is technically incorrect because a ";" is "comment to end-of-
> line" syntax and the line wrapping breaks that model.
None of these are wrapping in the .txt document I generated.  Made it a
single ;, but otherwise I think this is OK??
> There's been a discussion of the imprecision of case-sensitive vs. case-

> on the recent discussion.
I'm not convinced that changing this wins us anything, since this
document is almost entirely being read in the context of all the other
IMAP documents which use the "old" syntax.  Unless someone really cares,
I'd prefer to keep the syntax consistent with the related documents.

> ends can use the same id for two different objects.
Rewritten, and I used MUST NOT, because otherwise it's breaking the
MUSTs above.

> Appendix; that's also common in other RFCs.
Done.

>> o  Digest of (MailboxName/UIDVALIDITY/UID) - is not kept when copying>>  messages, but is guaranteed unique and doesn't require storage.

> that store a MAILBOXID but not EMAILID).
Just MAILBOXID/UID in that case, MailboxName/UIDVALIDITY is already
guaranteed to create a unique MAILBOXID.

> use of MD5 or SHA1 of the message content is not sufficient.
I didn't name any specific digests, but put wording in advising
monitoring current research.
Cheers,

Bron.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 24 Apr 2018 17:43:27 -0400

>> The ABNF is technically incorrect because a ";" is "comment to end-of-line"
>> syntax and the line wrapping breaks that model.
>

Yeh, I don't see any line-wrapping problems either.  Chris, can you be
specific about what lines you see that are odd?

> I'm not convinced that changing this wins us anything, since this document
> is almost entirely being read in the context of all the other IMAP documents
> which use the "old" syntax.  Unless someone really cares, I'd prefer to keep
> the syntax consistent with the related documents.

The thread Chris is talking about was a result of an errata report,
and the suggestion I had wasn't to specify it explicitly in the ABNF,
but to put a sentence in the document reminding readers about the
general IMAP rule.  That would involve adding a sentence such as the
following to Section 2:

"As with all IMAP extension documents, the case used in writing IMAP
protocol elements herein is chosen for editorial clarity, and
implementations must pay attention to the numbered rules at the
beginning of [RFC3501] Section 9."

My suggestion is that we put something like that in all IMAP extension
documents from here on, just to make it clear.

Barry

> delete "they". I suggest making that "unique within messages offered by a
> single IMAP client connection to a given IMAP server domain name." NOTE:
> allowing a proxy to combine multiple independent "servers" into a view with
> conflicting object ids would be bad. They have to be server-unique from the
> client's perspective so a server-side IMAP proxy SHOULD NOT advertise this
> extension if multiple back-ends can use the same id for two different
> objects.
>
>
> Rewritten, and I used MUST NOT, because otherwise it's breaking the MUSTs
> above.
>
> My editorial preference is to put non-normative suggestions in an Appendix;
> that's also common in other RFCs.
>
>
> Done.
>
> o Digest of (MailboxName/UIDVALIDITY/UID) - is not kept when copying
> Another suggestion is digest of MAILBOXID/UIDVALIDITY/UID (for servers that
> store a MAILBOXID but not EMAILID).
>
>
> emailed and threadid need to have a collision-resistant property, so use of
> MD5 or SHA1 of the message content is not sufficient.
>
>
> I didn't name any specific digests, but put wording in advising monitoring
> current research.
>
> Cheers,
>
> Bron.
>
> --

---

From: "Chris Newman" <[email-masked]>
Date: Tue, 24 Apr 2018 22:23:09 -0700

On 24 Apr 2018, at 14:43, Barry Leiba wrote:
>>> end-of-line"

Sorry, looks like that was fixed in -01; I must have been accidentally 
looking at -00 when writing that.

		- Chris

>> document
>> by a
>> MUSTs
>> use of
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=-GGuCuhjypSIPCi_uvlNOxfnhS_ycqS23NfoC99oHxg&s=_lPidqZyZu2H8v273fWGhSLfZkb12Hxl0IvHmHvW3zc&e=
>>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=-GGuCuhjypSIPCi_uvlNOxfnhS_ycqS23NfoC99oHxg&s=_lPidqZyZu2H8v273fWGhSLfZkb12Hxl0IvHmHvW3zc&e=