Subject: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.

From: Stephan Bosch <[email-masked]>
Date: Wed, 14 May 2014 01:09:55 +0200

Hi,

I just noticed that the IMAP METADATA and METADATA-SERVER capabilities
(RFC 5464) are not listed in the IANA IMAP capability registry:

http://www.iana.org/assignments/imap-capabilities/imap-capabilities.xhtml

Is there a particular reason for that?

Regards,

Stephan.

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 13 May 2014 21:13:45 -0400

Hi Stephan,

> Is there a particular reason for that?

Looks like the capabilities were not explicitly included in the IANA 
section of 5464 - my mistake - sorry. So this is an oversight. Perhaps 
Barry or Pete can request IANA to update the registry.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Tue, 13 May 2014 22:06:17 -0400

> Looks like the capabilities were not explicitly included in the IANA section
> of 5464 - my mistake - sorry. So this is an oversight. Perhaps Barry or Pete
> can request IANA to update the registry.

Yeh, I hate it when that happens; everyone missed it -- and both the
shepherd and responsible AD are experienced IMAP people.  These things
happen (and more so with individual submissions, I think, but
whatever...).

The easiest way to deal with this is for Cyrus to write a quick, short
draft like this:

----------------------------------------
1. Introduction [same as the Abstract]

The IMAP METADATA Extension [RFC5464] defined two new IMAP
capabilities -- METADATA and METADATA-SERVER -- but neglected to
register them.  This document corrects that oversight.

2. IANA Considerations

Please register METADATA and METADATA-SERVER in the IMAP Capabilities
registry <http://www.iana.org/assignments/imap-capabilities>, using
the reference [RFC5464].

3. Security Considerations

Making sure everything is registered is a Good Thing(tm).

4. Normative References

RFC5464 ...etc...
----------------------------------------

Really... that short.  Make it Experimental, because the registry
requires that or Stds Trk.  Post it, and immediately send me a
publication request, and I'll sponsor it.  Four week last call, next
telechat, should be done and registered within 6 weeks.  And that
avoids any questions about process.

b

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 13 May 2014 22:13:51 -0400

Hi Barry,

> The easiest way to deal with this is for Cyrus to write a quick, short

I don't mind doing that, but is it really necessary? Could we not treat 
this as an erratum? I note that several of the specs currently listed in 
the capabilities registry do not have an IANA section at all (e.g. RFC3502, 
RFC3516) - so some "special" action was taken for those.

-- 
Cyrus Daboo

---

From: Dave Cridland <[email-masked]>
Date: Wed, 14 May 2014 08:25:44 +0100

I think you can just send IANA an email, with the correct form, pointing to
the existing RFC. I don't think the process requires the form be in the
RFC, merely that there's an RFC defining the capability being registered.

Of course, the IESG will need to express their approval, somehow, too.

On 14 May 2014 03:13, Cyrus Daboo <[email-masked]> wrote:

> Hi Barry,
>
>
> --On May 13, 2014 at 10:06:17 PM -0400 Barry Leiba <
> [email-masked]> wrote:
>
> _______________________________________________
> imapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/imapext
>

---

From: Stephan Bosch <[email-masked]>
Date: Wed, 14 May 2014 18:08:41 +0200

(ohw, somehow mailing list got dropped from To:)

Cyrus Daboo schreef op 14-5-2014 17:26:
> OK.
>
> I was going to do a quick scan and see if any other capabilities are
> missing. Here is what I found:
>
> AUTH= (3501) Not sure this is needed given it is in the base spec itself.
>
> URLAUTH=BINARY (5524) - actually this is bad. The spec uses
> "URLAUTH=BINARY" in section 3, but uses "URLFETCH=BINARY" in the IANA
> section (which is registered). However, the Dovecot server I use has
> "URLAUTH=BINARY". I do not see any errata for 5524 so this issue needs
> to be addressed.

Ow. That is quite bad indeed.

We didn't notice that either. Dovecot implementation is based on the ABNF.

I know of at least one other server that supports this capability: Cyrus 
(http://www.imapwiki.org/Specs).

I quickly grepped the source code and, luckily, it uses "URLAUTH=BINARY" 
too.

Still, I wonder whether there are others. The list on the imapwiki is 
far from complete, nor up-to-date.

Isode was involved in writing this RFC, but I don't know whether they 
actually implemented it for their product. Dave?

Regards,

Stephan.

---

From: Jayantheesh S B <[email-masked]>
Date: Wed, 14 May 2014 18:29:54 +0000

Hi Cyrus Daboo,

If you are fine, we would like to contribute for this draft as Barry mentioned. 

Regards,
Jay
-----Original Message-----
From: Cyrus Daboo [mailto:[email-masked]] 
Sent: Tuesday, May 13, 2014 10:14 PM
To: Barry Leiba
Cc: Stephan Bosch; [email-masked]
Subject: Re: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.

Hi Barry,

> The easiest way to deal with this is for Cyrus to write a quick, short 

I don't mind doing that, but is it really necessary? Could we not treat this as an erratum? I note that several of the specs currently listed in the capabilities registry do not have an IANA section at all (e.g. RFC3502,
RFC3516) - so some "special" action was taken for those.

--
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Fri, 16 May 2014 22:16:03 -0400

> can request IANA to update the registry.

OK, so here's what we did:
The IESG agreed that this was an oversight, that 5464 serves fine as
the Standards Track reference, and that no further documentation is
needed to make the registration happen.  We approved the appropriate
registry update.  While we were at it, we also asked IANA to add
"AUTH=" with a reference to RFC 3501, which is also missing.  We
should see the updates in the registry soon, once IANA has time to
respond to the request.

The URLAUTH=BINARY vs URLFETCH=BINARY issue is more complicated, and
probably will require a quick documentation update to clear it up once
we're sure what the right fix is.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 May 2014 10:40:07 +0100

On 14/05/2014 17:08, Stephan Bosch wrote:
> I know of at least one other server that supports this capability: 
> Cyrus (http://www.imapwiki.org/Specs).
>
> I quickly grepped the source code and, luckily, it uses 
> "URLAUTH=BINARY" too.
>
No, we haven't implemented this. Although it might become more 
interesting in the future.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 May 2014 15:04:33 -0400

The change has been made in the registry.

Barry