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

[Tony Hansen <tony at att.com>]

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
	tony at att.com

Ned Freed wrote:
>> 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.
> 
> 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
>> 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.)
> 
> 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.
> 
>> 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.
> 
> 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.
> 
>> 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
> 
>>   [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
> 
> _______________________________________________
> lemonade mailing list
> lemonade at ietf.org
> https://www1.ietf.org/mailman/listinfo/lemonade

_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade