Re: [imapext] IMAP Capability Registry and RFC 5524: URLFETCH=BINARY vs URLAUTH=BINARY

Hello,

please comment on the following proposed erratum to RFC 5524 within a
month:

Type EDITORIAL (not TECHNICAL)

Current Text:

6.  IANA Considerations

   This document defines the URLFETCH=BINARY IMAP capability.  IANA has
   added it to the registry accordingly.

New Text:

   This document defines the URLAUTH=BINARY IMAP capability.  IANA is
   asked to replace URLFETCH=BINARY with URLAUTH=BINARY in the IMAP 
   registry.

Motivation:
  This document talks about URLAUTH=BINARY.  Mentioning URLFETCH=BINARY
  in the IANA section was not intended.

On Wed, 2020-05-20 at 08:15 +0100, Dave Cridland wrote:
> Oh.
> It looks like I made a mistake in the IANA section, that was subtle
> enough never to be noticed by any of the reviewers or the editors, or
> indeed IANA. That was clever of me, wasn't it?
> 
> Given that the specification refers only to URLAUTH in defining the
> behaviour of the server, I think the IANA section is solely at fault,
> such means I have managed to get an errata into the registry.
> 
> Do I get a prize? Or a lifetime ban from writing any more RFCs?
> 
> Dave.
> 
> On Tue, 19 May 2020, 16:49 Alexey Melnikov,
> <alexey.melnikov@isode.com> wrote:
> >  
> >  Hi Дилян,
> >  On 17/05/2020 15:55, Дилян Палаузов wrote:
> >  
> >  
> > >  
> > > Hello,
> > > 
> > > The Internet Message Access Protocol (IMAP) Capabilities Registry
> > > at
> > > https://www.iana.org/assignments/imap-capabilities/imap-capabilities.xhtml
> > > says:
> > > 
> > > URLFETCH=BINARY 	[RFC5524]
> > > 
> > > and RFC 5524, https://tools.ietf.org/html/rfc5524 says:
> > > 
> > > 
> > > 3.  Extended URLFETCH
> > > 
> > >    This extension is available in any IMAP server implementation
> > > that
> > >    includes URLAUTH=BINARY within its capability string.
> > > 
> > > 5. Formal Syntax
> > > 
> > >    capability       =/ "URLAUTH=BINARY"
> > > 
> > > 6.  IANA Considerations
> > > 
> > >    This document defines the URLFETCH=BINARY IMAP capability. 
> > > IANA has
> > >    added it to the registry accordingly.
> > > 
> > > My reading is, that the URLAUTH=BINARY and URLFETCH=BINARY
> > > capabilities
> > > mean the same.
> > >  
> >  I think one of these is a typo. I suspect "URLFETCH=BINARY" should
> > be "URLAUTH=BINARY", because "URLAUTH" is already registered as a
> > Capability. Dave? 
> > >  
> > > Please comment within a month on the following proposal for
> > > erratum:
> > > 
> > > New text:
> > > 
> > > 3.  Extended URLFETCH
> > > 
> > >    This extension is available in any IMAP server implementation
> > > that
> > >    includes URLAUTH=BINARY or URLFETCH=BINARY within its
> > > capability
> > >    string.
> > > 
> > > 5.  Formal Syntax
> > > 
> > >  capability       =/ "URLAUTH=BINARY" / "URLFETCH=BINARY"
> > > 
> > >       ; Command parameters; see Section 3.1
> > > 
> > > 6.  IANA Considerations
> > > 
> > >    This document defines the URLFETCH=BINARY and the
> > > URLAUTH=BINARY
> > > IMAP capabilities.  Both capabilities mean the same. IANA has
> > > added 
> > > URLFETCH=BINARY and will add URLAUTH=BINARY to the registry 
> > > accordingly.
> > >  
> >  If it is a typo, I would edit your suggestion to recommend one or
> > another, not both.
> >  Best Regards,
> >  Alexey
> >  
> >  
> > >  
> > > I do not insist to do the wording, anybody can take this over.
> > > 
> > > If there is knowledge, that all implementations have consolidated
> > > on a
> > > single capability wording, then the erratum can get smaller.
> > > 
> > > Greetings
> > >   Дилян
> > > 
> > > _______________________________________________
> > > imapext mailing list
> > > imapext@ietf.org
> > > https://www.ietf.org/mailman/listinfo/imapext
> > >  
> >  
> _______________________________________________
> imapext mailing list
> imapext@ietf.org
> https://www.ietf.org/mailman/listinfo/imapext