I'm resending this because it didn't seem to make it out the first time.
My apologies if you do get it twice.
I'm adding the AVT WG to this message to get people's comments there.
I've reset the subject line. In summary, Michael warns that we will live
to regret reassigning some of the event codes. We should either retire
the unused 2833 event codes permanently or at least make them the last
to be reassigned.
So the question to the list is whether we are committed to the new code
assignments already, or whether we can reconsider before the IESG gives
its final approval.
To give an idea of the number of changes that would be required to carry
this out:
In 2833bis:
Change the IANA Considerations section to reserve the following code
ranges against reassignment until all others are exhausted: 16, 41-48,
64-89, 96-112, 138-143 (some ambiguity), 160-167, 170-173. With the
further changes described below, this will leave the following ranges
free for immediate use: 17-22, 50-51, 90-95, 113-120, 169, and 206-255.
It also leaves all of the deprecated 2833 events easily revivable if
someone wants to write an RFC to bring them back to life.
In 2833bisdata:
We changed the meaning of some of the V.8bis signals, so we should
probably assign new codes to them if we are being careful. This applies
to CRdSeg, CReSeg, MRdSeg, and MReSeg. Say that these would get the
currently unassigned codes 23, 24, 25, and 26.
New codes V8bISeg, V8bRSeg, V32AC, V21L300, and V21H300 use codes that
RFC 2833 assigned to line events. Give them codes 27, 28, 29, 30, and 31
instead.
In 2833biscas:
Events 138-142 may or may not have been redefined -- it's hard to know
because the old events had non-standard designations and it's hard to
interpret the assignment of "MF S1 ... S3" into the two codes 142-143.
So for safety's sake, reassign as follows:
MF Code 11 or KP3P/ST3P = 123
MF KP or KP1 = 124
MF KP2 or KP2P/ST2P = 125
MF ST = 126
MF Code 12 or KP'/STP = 127
The 16 ABCD events were never assigned to specific bit configurations in
RFC 2833, but my research suggested that if they were ever used, the
assignment was as we have it now. So I think we're safe in leaving those
codes unchanged.
RFC 2833 assigned five different codes to continuity testing. I boiled
these down to two and arbitrarily put them together (codes 167, 168)
without matching the old semantics. Because the frequencies used in the
RFC 2833 descriptions do not match those used in the standards cited in
2833biscas, it seems best to assign new codes:
Continuity check-tone = 121
Continuity verify-tone = 122
Michael A. Patton wrote:
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
