Subject: [lemonade] WGLC compress-02: multiple COMPRESS algorithms

From: Tony Hansen <[email-masked]>
Date: Mon, 31 Jul 2006 10:56:52 -0400

I think the following covers all that is needed to handle the
possibility of future algorithms being needed, while making it suitably
difficult to actually add one.

*IF* in the future, another algorithm were added, and a server supported
both algorithms, how would the additional algorithms be announced? I
think we should choose a method comparable to that used in other
mechanisms that allow multiple values, that is, a comma separated list.

There is no ABNF specified for the COMPRESS capability, so we need to
add this to the ABNF section.

	capability =/ "COMPRESS=" algorithm-list
	algorithm-list = algorithm *["," algorithm]

Just in case, some future algorithms may require arguments to be passed.
I suggest adding the following to the compress ABNF:

        compress    = "COMPRESS" SP algorithm *[SP argument]
	argument    = 1*TEXT

For the IANA considerations section, I think the following would be
appropriate:

7. IANA Considerations

    The IANA is requested to add COMPRESS=DEFLATE to the list of IMAP
    extensions.

    The IANA is requested to maintain one new registry: IMAP Compression
    Algorithms. The registry's purpose is to register compression
    algorithms that may be used with this extension.  New IMAP
    algorithms MUST be defined in a standards track or IESG approved
    experimental RFC.  New IMAP compression algorithms MUST include the
    following information as part of their definition:

	algorithm identifier
	optional arguments
	standard commands affected
	specification reference
	discussion

That's it.

	Tony Hansen
	[email-masked]

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Tony Hansen <[email-masked]>
Date: Mon, 31 Jul 2006 11:02:30 -0400

One addition, below.

	Tony

> 	standard commands affected

    One IMAP compression algorithm is defined in this document, with the
    following registration definition:

      algorithm identifier: DEFLATE
      optional arguments: none
      standard commands affected: none
      specification reference: RFC 1951 and XXXX
      discussion: see RFC XXXX

    [RFC-EDITOR NOTE: change XXXX to this RFC number]

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 31 Jul 2006 16:22:12 +0100

>	algorithm-list = algorithm *["," algorithm]
I think we should use:

	capability =/ "COMPRESS=" algorithm
                      ;; multiple COMPRESS capabilities allowed

because existing clients don't usually parse anything after the '=' sign.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 31 Jul 2006 16:36:54 +0100

> because existing clients don't usually parse anything after the '=' 
I'm happier with that too, it matches how AUTH and THREAD work.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 31 Jul 2006 16:45:32 +0100

More comments below.

>        compress    = "COMPRESS" SP algorithm *[SP argument]
Should this be "astring" at least?

I suggest we either use RFC 4466 or not define any extensions at all. I 
prefer the latter.

>    following information as part of their definition:
I would change this to "optional arguments to COMPRESS command"

>	standard commands affected
It is also common to have a contact email address (or Author/controller).

---

From: Mark Crispin <[email-masked]>
Date: Mon, 31 Jul 2006 08:47:54 -0700 (PDT)

> Should this be "astring" at least?

atom.  Please.

> I suggest we either use RFC 4466 or not define any extensions at all. I 

+1

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 31 Jul 2006 17:50:57 +0200

> I'm happier with that too, it matches how AUTH and THREAD work.

Agreed. In fact I'm very unhappy with anything else (absent arguments).

I'll publish a new draft tomorrow, including (AFAICR) all suggested changes.

Arnt

---

From: Tony Hansen <[email-masked]>
Date: Mon, 31 Jul 2006 12:11:06 -0400

>> Should this be "astring" at least?

atom is fine.

	Tony Hansen
	[email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Mon, 31 Jul 2006 12:25:00 -0400

> Agreed. In fact I'm very unhappy with anything else (absent arguments).

This is fine.

The intro should correspondingly be changed to:

    A server which supports the COMPRESS extension indicates this with
    one or more capability names consisting of "COMPRESS=" followed by a
    supported compression algorithm name as described in this document.

    The goal of the COMPRESS extension is to reduce the bandwidth usage
    of IMAP.  On regular IMAP connections, the PPP or MNP compression
    used with many low-bandwidth links compresses IMAP well. However,
    when TLS is used, PPP/MNP compression is ineffective. TLS too may
    provide compression, but a careful IMAP implementation can do much
    better.

    In order to increase interoperation, it is desirable to have as few
    different compression algorithms as possible, so this document
    specifies only one, DEFLATE.  The DEFLATE algorithm is standard,
    widely available, unencumbered by patents and fairly efficient.
    Hopefully it will not be necessary to define additional algorithms.

	Tony Hansen
	[email-masked]