[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lemonade] Re: WGLC compress-02 IANA registry
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