Date: Mon, 05 Jun 2006 10:53:16 -0400
From: "Tom-PT Taylor" <[EMAIL PROTECTED]>
Please see my responses below. I have made a number of changes based on
your review. The document is better for it.
Thanks. That's one of the goals of GenART, to improve readability...
Michael A. Patton wrote:
> In the Abstract, we have "The remainder of the event codes defined in
> RFC 2833 are deprecated." However, I don't actually see that in the
> document. I would expect to see the IANA Considerations list the
> deprecated codes, so that the initial content of the registry marks
> them to avoid reuse. Later, I do note that these _are_ given in
> Appendix A. Shouldn't these be included in the IANA Considerations so
> that IANA doesn't miss them?
>
[PTT] I've added a list of codes reserved for the data and
channel-associated signalling documents to the IANA Considerations
section in 2833bis, and modified the language in the appendix. A
qualification here: we have assumed that no one ever implemented the
retired codes.
It's not really possible to know that there were absolutely no
implementations. I know in the DNS we made that assumption at one
point and when the new use for an old code was well deployed, we
finally ran into the one case where it had...and the appearance of the
new use made a widely deployed appliance (with ROM implementation)
malfunction, leaving us with a very hard choice. It's from that
experience that I recommend against ever re-using a code, even if
every participant in the WG "knows" that they were never implemented.
If the code space is small enough that codes will eventually be
reused, the obsolete code points should so be marked and reuse should
be delayed as long as possible.
This was rather clear in at least one case, simply because the old
assignment had an error that would have made it unimplementable.
Just because the spec was broken doesn't mean that there wasn't some
engineer somewhere who was forced to include it by clueless management
and so he or she just did something... I have a number of good
stories about this, including the engineer whose management insisted
that every TELNET option be implemented, including the one byte code
with value 256!
We asked on the list before making the changes, of course.
And, of course, anyone who would implement the obviously broken codes
would be someone who isn't involved and therefore not on the list.
Some of the codes have actually been reassigned to other uses.
The others are considered available for assignment as required.
I'll reiterate that I think it's extremely bad practice to reuse
codepoints, no matter how certain you are that the old value was never
used. The Internet is a really big place and someone somewhere may
well have used it and not told you. When that use comes out several
years from now and things start breaking, it will be very hard to
fix. It's much easier to just write off the codepoint in nearly every
case.
[PTT] Added the words "Provided that gateway design includes robust, low
overhead tone generation, ..." at the start of the sentence.
That's sufficient. If there was more time, I might try coming up with
a wording that makes it clearer. But, I don't suppose anyone will
actually do the silly thing, so it doesn't need much emphasis.
> When I hit Section 1.4, ... Perhaps replacing the first
> paragraph of 1.4 with something like this:
>
> This document provides ...
[PTT] Made changes in the spirit of this proposal. Modified the
introductory paragraph just cited and also added a sentence or two for
each of the listed methods.
Good, I actually like your version even better...
> In 2.4.1 the <list of values> is explicitly allowed to be unordered.
> I assume that also applies in 2.4. It should probably be mentioned
> there, and by extension in 7.1.1 as well. None of the three places
> mentions what to do with overlapping ranges. Are they disallowed or
> allowed and if allowed, what does it mean? Either they should be
> explicitly disallowed (I don't expect any implementation to ever
> need to generate them), or specify what to do with them (I expect
> "union" is the right operator).
>
[PTT] Rewrote the applicable paragraph of 2.4 as follows, and copied it
to the media type registration:
New versions of 2.4 and 2.4.1 address my concerns. You didn't mention
7.1.1, but a glance at the new draft shows it was fixed as well.
-MAP
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
