Re: [MMUSIC] Poll for path on ICE extensions and updates/corrections

[Harald Alvestrand <[e-mail]>]

My personal 2 cents:

The most wrong thing here is doing nothing at all, blocking progress on 
ICE refinement/extension work. This will result in people doing private 
extensions without findable, publicly reviewed documentation. Luckily, 
that's not a proposed alternative.

The second most wrong thing is to make everything depend on everything 
else, so that nothing comes out of the process until everything's 
finished. Given our collective experience with finishing ICE specs, this 
could easily become indistinguishable from the most wrong thing.
This is what I'm afraid will happen if we choose alternative a) below.

Looking at the alternatives:

On 09/19/2012 09:23 AM, Miguel A. Garcia wrote:
> a) Create a revision of ICE (i.e., a document what will obsolete RFC 
> 5245), including all the extensions and corrections that
> we want to choose from the list. This sounds like a big effort in
> time, and presumably will create a big spec. We should make sure that
> people have enough cycles to devote to this activity.
As should be clear from the above, I do not prefer this.
>
> b) Create a revision of ICE (obsoleting RFC 5245), but only addressing
> bug fixing and opening hooks to extensions, with the idea that
> extensions won't need to violate 5245bis. Additionally, document each
> extension in a separate RFC. Extensions will depend and refer to the
> 5245bis draft.
(Tangent: I would like to extend this to one more task: If any piece or 
aspect of RFC 5245 can be isolated from the base spec and made into a 
separate document, it should be. RFC 5245, at 117 pretty dense pages, is 
a mouthful.)

This is the approach that's been taken with, for instance, SMTP (RFC 822 
/ 2822 / 5322).
>
> c) Leave the current ICE core spec as is. Document each extension
> separately (referring to 5245). Create open or more documents listing
> bug fixes and corrections (will also update RFC 5245). 
This is the approach taken with the DNS, leading to these wonderfully 
transparent protocol definitions from the RFC index:

1034 Domain names - concepts and facilities. P.V. Mockapetris.
      November 1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973,
      RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876,
      RFC1982, RFC2065, RFC2181, RFC2308, RFC2535, RFC4033, RFC4034,
      RFC4035, RFC4343, RFC4035, RFC4592, RFC5936) (Also STD0013) (Status:
      STANDARD)

1035 Domain names - implementation and specification. P.V.
      Mockapetris. November 1987. (Format: TXT=125626 bytes) (Obsoletes
      RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348,
      RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181,
      RFC2137, RFC2308, RFC2535, RFC2845, RFC3425, RFC3658, RFC4033,
      RFC4034, RFC4035, RFC4343, RFC5936, RFC5966) (Also STD0013) (Status:
      STANDARD)

Both B and C are approaches we have experience with, and neither has 
been abandoned by the people who used them.

However, I have a strong preference for the document structure that 
comes out of doing B.