[Extra] Eric Rescorla's No Objection on draft-ietf-extra-imap-objectid-07: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Tue, 31 July 2018 22:50 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-imap-objectid@ietf.org, Jiankang Yao <yaojk@cnnic.cn>, extra-chairs@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153307744579.3110.9297337364956440515.idtracker@ietfa.amsl.com>
Date: Tue, 31 Jul 2018 15:50:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/cGsLqMm9z_41CPmvjb4bmnq6VYU>
Subject: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-imap-objectid-07: (with COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-extra-imap-objectid-07: No Objection

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

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D7116



IMPORTANT
S 11.
>      If a digest is used for ID generation, it must have a collision
>      resistent property, so server implementations are advised to monitor
>      current security research and choose secure digests.
>   
>      The use of a digest for ID generation may be used as proof that a
>      particular sequence of bytes was seen by the server.

I don't understand this text. How does the client know whether a
digest was sued.

COMMENTS
S 7.
>      IMAP ABNF extensions [RFC4466] specifications.
>   
>      Except as noted otherwise, all alphabetic characters are case-
>      insensitive.  The use of upper- or lowercase characters to define
>      token strings is for editorial clarity only.  Implementations MUST
>      accept these strings in a case-insensitive fashion.

For clarity: IDs are not case insensitive, right? Because otherwise
the text below about differing  in case doesn't make sense.


S 8.1.
>   
>      o  ids which contain only digits
>   
>      o  ids which differ only by ASCII case (A vs a)
>   
>      o  the specific sequence of 3 characters NIL

Nit. Do you want to quote "NIL"?

[Extra] Eric Rescorla's No Objection on draft-iet… Eric Rescorla
Re: [Extra] Eric Rescorla's No Objection on draft… Bron Gondwana