Subject: Re: [lemonade] Re: WGLC compress-02 IANA registry

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 1 Aug 2006 18:40:05 +0200

Alexey Melnikov <[email-masked]>
> Dave Cridland wrote:
> > I actually think that a better way forward would be to define a 
> > distinct document which created the IANA registry and populated it 
> > with DEFLATE as the MTI, and then subsequently this document would 
> > then reference it.
> 
> After writing draft on comparators Arnt should be an expert on IANA 
> registrations ;-).

That's why Arnt doesn't want to bother the IANA except when it's
important ;)

(The -03 revision creates a registry, even though I personally think
it's not justified.)

Arnt

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

---

From: Randall Gellens <[email-masked]>
Date: Tue, 1 Aug 2006 17:46:59 -0700

At 8:15 PM -0700 7/28/06, Mark Crispin wrote:

>  On Fri, 28 Jul 2006, Philip Guenther wrote:
>>  I don't think we expect to see future THREAD mechanisms either, 
>> but it's apparently simpler and less contentious to create a 
>> registry than it is to _not_ do so.  As author/editor/review time 
>> is the most precious commodity in the IETF, creating the registry 
>> and copying text to do so that people have already nodded their 
>> heads at seem like the most efficient choice.

I get a bit queasy at the thought of IANA registry pollution 
(creating useless registries) just because it is easier for us to do 
that than to include a sentence in the document as to why one isn't 
needed.

IANA is trying to speed up its response times.  Adding useless work hurts that.

>  Excellent point.
>
>  It's also important to note that creating a registry is a great way 
> to prevent bad ideas from getting into a protocol.  If you don't 
> have a registry, then everybody who thinks that he has a Very 
> Important Idea will fillibuster the specification until the bad 
> idea is added to the specification.  With a registry, the people 
> with VIIs have an outlet, but then have to make the VII stand on 
> its own (which few VIIs will actually accomplish).

Perhaps I'm naive, but I think we can block bad ideas from being 
added to our document just as easily (in fact, more easily) as we can 
block them as stand-alone additions to an IANA registry.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
If I like it I say it's mine.  If I don't I say it's a fake.
    --Pablo Picasso

---

From: Ned Freed <[email-masked]>
Date: Tue, 01 Aug 2006 18:50:54 -0700 (PDT)

> (The -03 revision creates a registry, even though I personally think

What I'm not getting is why a registry separate from the one we already
have for TLS compression schemes is needed. The table already exists:

  http://www.iana.org/assignments/comp-meth-ids

All we need to do is add a column for an identifier name (as opposed to
identifier value) and we should be good to go.

The advantage of doing it this way is that every time someone adds a
compression scheme to TLS it's available for use as a compression layer,
and vice versa.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 2 Aug 2006 10:00:45 +0200

Ned Freed writes:
> What I'm not getting is why a registry separate from the one we 
> already have for TLS compression schemes is needed. The table already 
> exists:
>
> All we need to do is add a column for an identifier name (as opposed 
> to identifier value) and we should be good to go.

I looked at that table, and the change needed seemed to be a little too 
much butchery.

I contemplated using the description column (which happens to contain 
suitable strings). Seemed a bit hackish. Opportunistic reuse.

Adding a third column means there's two references for each line, which 
seemed wrong, and also I thought it might be impossible to alter the 
format of an existing IANA registry.

So... I thought it would be cleanest to use a separate registry, and 
made a note to make it easy for the IANA (see yesterday's message) by 
sending the rfc-editor two files: The RFC in nroff format and 
additionally a text file containing the complete registry.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 2 Aug 2006 10:18:19 +0200

Thinking about it again:

If I create a registry, the IANA has to do that. If I modify 
comp-meth-tls, the IANA has to do that. Seems about the same, with 
modification perhaps a touch more work since it's less routine. If I 
don't create a registry, the IANA needs to do nothing now, but the 
result is different from several other IMAP extensions (SORT and THREAD 
notably), which is arguably inferior. (Yes, I know I'm a bit fascist 
about this consistency thing.)

For each new algorithm, which I fervently hope never happens, the IANA 
has to add an antry to one registry. Either to imap4-capabilities, 
comp-meth-tls or comp-meth-imap. Seems the same.

So I think it doesn't really make a difference for the IANA.

I hear a couple of people wanting a registry and a couple not. I can't 
confidently say one side is stronger. I've set the reply-to field on 
this message to emulate a hum, so if everyone with an opinion can just 
check one, I can make a quick -04 revision if needed:

  [ ] hum for piggybacking on imap4-capabilities using 
"COMPRESS=<algorithm>" entries, like -02 revision

  [ ] hum for new registry, like -03 revision, and like SORT/THREAD

  [ ] hum for modifying and using comp-meth-tls registry, without 
precedent AFAIK

Arnt

---

From: Ned Freed <[email-masked]>
Date: Wed, 02 Aug 2006 17:13:35 -0700 (PDT)

> modification perhaps a touch more work since it's less routine.

Generalizations here are difficult since the staff and abilities of IANA have
changed considerably over time, but my experience has been more or less the
exact opposite: Getting new registries created has proved to be harder than
tweaking an existing registry.

The key factor in how difficult registry creation and/or tweaking seems to be
the complexity of the registration process itself. And this no longer seems to
be the problem it used to be now that we have various canned models available.

> If I

I like consistency too, but I'm more concerned about having a consistent set of
registries for the things we do register than I am for having registries for
all things that might ever get extended.

> comp-meth-tls or comp-meth-imap. Seems the same.

Assuming a new algorithm comes along, wouldn't it make sense to register it for
use in both TLS and COMPRESS? It isn't much more work, but it is more work.

> So I think it doesn't really make a difference for the IANA.

I'm not sure the degree of difference of work is the main factor here in any
case. I want things to work well even if that means more work for all
concerned.

>   [x] hum for modifying and using comp-meth-tls registry, without
> precedent AFAIK

I vote for the third of these and I also note that there are precedents. The
most obvious one is the media types registry. This was originally specific to
MIME, but was subsequently adopted for use with HTTP, then with SDP/RTSP/SIP
and now they're all over the place.

Defining a single registry that's heavily used and is defined appropriately for
some very different protocols has not been easy, but the alternative of having
multiple overlapping registries for media types is just too awful to
contemplate.

Another case I'm familiar with is the content disposition registry. This was
originally set up for email but is now used by SIP and probably others. And
this one points out the risks of having separate registries for the same
general sorts of things: We weren't paying attention when SIP started using
disposition values and we came within inches of approving what amounted to
conflicting registrations.

Now, in the present case it is likely that there will be no additional
values registered, or a least very few will be. So this may well be a largely
academic exercise, and I can't get excited if we decide on two registries.
But I do think it is the wrong choice.

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Wed, 02 Aug 2006 21:08:26 -0400

Using a separate registry, I was trying to make it harder to add future
algorithms.

If we modify comp-meth-tls, is that going to suddenly swamp us with lots
of potential algorithms and make interop testing harder?

	Tony Hansen
	[email-masked]

---

From: Dave Cridland <[email-masked]>
Date: Thu, 03 Aug 2006 09:30:25 +0100

> of potential algorithms and make interop testing harder?

I had assumed that if we allow for multiple algorithms by any 
mechanism, then DEFLATE would become a Mandatory To Implement 
algorithm.

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: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 3 Aug 2006 11:14:36 +0200

Dave Cridland writes:
>> Using a separate registry, I was trying to make it harder to add 
>> future algorithms.
>>
>> If we modify comp-meth-tls, is that going to suddenly swamp us with 
>> lots of potential algorithms and make interop testing harder?
>

I forgot to put that in. Sorry. There's also a wrong reference in -03, 
so a -04 is necessary. I'll do it once the chair have interpreted 
yesterday's hummish thingy. Possibly tomorrow, more likely Tuesday.

But Tony is right. To test interoperation, we need to test the algorithm 
each client-server pair chooses to use. If a given client and server 
both support LZS and DEFLATE, and the client prefers LZS (see 
comp-meth-ids), then we need to to test that they correctly choose LZS 
when talking to each other, and that their LZS implementations 
interoperate.

Arnt