Re: [Extra] AD review of draft-ietf-extra-imap-fetch-preview-00

[Michael Slusarz <[e-mail]>]

I've edited the draft based on comments in this thread and have pushed -01.

One comment requires further discussion:

> > If we do add a registry, I think the text in ABNF section should be changed from:
> >
> > "New algorithms MUST be registered with IANA"
> >
> > to:
> >
> > "New algorithm names MUST conform with the recommendations described in RFC 6648, Section 3"
> >
> > See: https://tools.ietf.org/html/rfc6648#section-3
> 
> I am happy with the <https://tools.ietf.org/html/rfc6648#section-3> 
> reference, but I think it would be better to say both:
> 
> "New algorithm names MUST be registered with IANA and MUST conform with the recommendations described in RFC 6648, Section 3"

On additional review, and re-reading RFC 6648, I think the correct language is to omit the "MUST be registered" language.

One of the goals of this spec is to allow flexibility for local implementers to expand the PREVIEW functionality as they see fit.  (We are already thinking about at least one additional algorithm we might implement.)  These additional algorithms/modifiers may only be relevant to a single project/customer/use-case however, so they are not necessarily something that will ever be standardized.

RFC 6648, at least by my reading, explicitly allows this non-standardization path and simply asks someone implementing to follow some steps to attempt to avoid things like naming collisions.

So to me, it seems like we shouldn't require any new PREVIEW algorithms to "MUST be registered with IANA" - instead, simply make sure they are semantically correct (ABNF), and follow agreed-upon conventions (RFC 6648), and that is all we ask.

michael