Re: [Extra] Adam Roach's Yes on draft-ietf-extra-imap-objectid-07: (with COMMENT)

[Bron Gondwana <[e-mail]>]

On Wed, Aug 1, 2018, at 10:34, Adam Roach wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-extra-imap-objectid-07: Yes

Thanks for your detailed feedback!  Responses below.  I'm updating my
source file for v-08.
> When responding, please keep the subject line intact and reply to all> email addresses included in the To and CC lines. (Feel free to
> cut this> introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/
> 
> 
> 
> ----------------------------------------------------------------------> COMMENT:
> ----------------------------------------------------------------------> 
> Thanks for the work that went into defining this mechanism -- it
> seems like a> very useful optimization. I have a few minor comments.
> 
> -------------------------------------------------------------------
> --------> 
> §7:
> 
>>   resp-text-code =/ "MAILBOXID" SP "(" objectid ")"
>>           ; incorporated before the expansion rule of
>>           ;  atom [SP 1*<any TEXT-CHAR except "]">]
>>           ; that appears in [@!RFC3501]
> 
> The "<" and ">" in the preceding text should be replaced with literal> less-than and greater-than symbols.

Hmm, yes - this is roundtripping the markdown just fine now.  Removed.

> -------------------------------------------------------------------
> --------> 
> §8.1:
> 
>> An objectid is a string of 1 to 255 characters from the following set>> of 64 codepoints. a-z, A-Z, 0-9, '_', '-'.
> 
> It would probably be helpful for implementors if this section
> indicated that> these are the same characters used by the "base64url" encoding
> defined in RFC> 4648. Doing so will let implementors know that they can use existing
> implementations of base64url to convert the output of a hash
> function into a> syntactically valid objectid.

Thanks, I have added an informative reference to RFC4648 in the objectid
definition.
> -------------------------------------------------------------------
> --------> 
> §11:
> 
>> The use of a digest for ID generation may be used as proof that a
>> particular sequence of bytes was seen by the server, however this is>> only a risk if IDs are leaked to clients who don't have permission to>> fetch the data directly.  Servers that are expected to handle highly>> sensitive data should consider using a ID generation mechanism which>> doesn't derive from a digest.
> 
> Couldn't this be addressed with a per-user salt value rather than a
> non-digest> identifier?

I've just changed it to "Servers that are expected to handle highly
sensitive data should consider this when choosing how to create IDs."
Here's a risk, consider if it applies to you.  Done.
Cheers,

Bron.


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]