[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Requirements I-D
- To: idn@ops.ietf.org
- Subject: Re: [idn] Requirements I-D
- From: Paul Hoffman / IMC <phoffman@imc.org>
- Date: Sat, 13 May 2000 20:01:56 -0700
- Delivery-date: Sat, 13 May 2000 20:04:16 -0700
- Envelope-to: idn-data@psg.com
At 2:38 AM +0800 5/14/00, James Seng wrote:
>I proposed to remove the following requirements: [6], [8], [12], [17], [32],
>[36], [38], [39] and to tone-down/rewrite: [4], [9], [33].
It would be good to know your reasoning on these. My take is:
[6] - Drop it: it's a design goal, not a requirement
[8] - Keep. The user interaction is important
[12] - Keep. It lays down the restrictions on protocols that demand
multiple charsets
[17] - Reword to say that IDN is a protocol, not an interface.
[32] - Drop or keep. Whatever we come up with, there will be tools to
make zone files as easily editable as they are now.
[36] - Keep. DNSSEC is pretty darn important, and we aren't going to
be able to say that IDN is more important than DNSSEC.
[38] - Drop. Pretty silly.
[39] - Drop. We'll consider anything.
[4] - Drop or roll into [12].
[9] - Drop. We shouldn't predefine that there will be a transition
period or how ASCII will be used.
[33] - Tone down. Certainly, we should strive for the least overhead
both in terms of packet size and in terms of round trips. But "shall
not" is a desire, not a requirement.
>In addition, we need to discuss the section on canoicalization, this section
>is most problemtic :P
>
>i think we can work on this section in 2 ways.
>
>1. continue to bash our head against on this section; or
>
>2. remove the whole section and leave it to open for the proposal.
I propose we keep bashing. [21] and [22] are not requirements, they
are introductory text for the rest of the section. [23] could be
reworded because the term "folding" is not commonly used with
ligatures and punctuation. [24], [25], [26], [27] (other than the
folding wording), [29], and [31] seem fine as is. [28] should be
removed (and there were certainly more than 1 request to do so). [30]
should be removed because it conflicts.
>Lastly, take a look at the number of RFCs we need to review.
Yup, it's a big number.
--Paul Hoffman, Director
--Internet Mail Consortium