Re: [idn] Requirements I-D

[James Seng <jseng@pobox.org.sg>]

Paul Hoffman / IMC wrote:
> 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

Yes. Implementations will handle this, somehow, maybe, hopefully, I guess. :-)

> [8] - Keep. The user interaction is important

Ah. the reason I asked it to be remove is *because* it is user interaction.
(Refer to the diagram on page 4. See the BIG box?)

> [12] - Keep. It lays down the restrictions on protocols that demand
> multiple charsets

It is confusing. And it is also written in such a way that there is no other
CCS(s) other than ISO10646 can meet the requirement so it become pointless. :P

1. If the WG has decided to use ISO10646 (like it is written), then 
   elimiate this and just say "Unicode only".

2. If the WG is willing to be more open minded, then it should rewrite it to
   be more friendly for multiple CCS design.

> [17] - Reword to say that IDN is a protocol, not an interface.

Conflict with [9] - fall back ASCII mechanism implies there *might* be two way
to represent a single domain...or from another perspective, it might not
because you can consider the fall back ASCII mechanism as a separate domain
name... 

Anyway, see the BIG box on page 4 too. Input and display should not be our
concern.

> [32] - Drop or keep. Whatever we come up with, there will be tools to
> make zone files as easily editable as they are now.

See BIG box on page 4. :-)

Ok, I know zonefile has been standardized before. but i dont think we should
worried how administrator going to edit their zonefiles, at least not in the
requirement stage. Yes, it is *nice* to have, but not a requirement.

e.g. zone data can be resident in a SQL database :P Are we going to define the
schema for the SQL table?

"editibity" of the zonefile is the least worries we have now. I am sure
application tools can be developed to help along with this.

> [36] - Keep. DNSSEC is pretty darn important, and we aren't going to
> be able to say that IDN is more important than DNSSEC.

I am inclined to say "IDN must be compatible with DNSSEC" and leave it as
that.

Zonefiles, signed or unsigned shldnt be a requirement.

On a hypotentically implementation of IDN, suppose we use UTF-8 on the wire
but we allow administrator to manage zonefiles in native encoding, e.g. SJIS
(Japanese). The name server, on loading of the zone see "$ENCODING SJIS", load
in the zone and internally convert to UTF-8.

How to keep this compatible with DNSSEC? Well, the signing program takes a
zonefile, load it in, convert internally to UTF-8, sign it, and spit out a
signed zone in UTF-8 with "$ENCODING UTF-8".

Does this "work" and retains compatibility with DNSSEC? Yes.
DOes this complience with [36]? No. (At least not the last line of [36])

> [38] - Drop. Pretty silly.

It is obvious to the point. 

> [39] - Drop. We'll consider anything.

I can imaging a protocol proposal saying "The protocol, to be complience with
R36, has considered the following new features of DNS: ... but has decided
none of them useful and decided not to do anything with it." *rofl*

> [4] - Drop or roll into [12].

Depending on how we want to deal with [12].

> [9] - Drop. We shouldn't predefine that there will be a transition
> period or how ASCII will be used.

Yes, it limits the flexibility of protocol proposals. 

> [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.

Look in this way.

1. If we are resolving ASCII domain names, then it must not (should not) have
    more overhead. (ie. all existing domain names must not suffer performance
    hits due to IDN).

2. If we are resolving IDN domain names, then it may have additional overhead.
   Expecting IDN domain names to generate "less traffic" is very subjective.
   I presume IDN packets will be larger RR than ASCII one so overall traffic
   is going to be higher :P
 
> I propose we keep bashing. 

Okie...More fun ahead :P 

> [21] and [22] are not requirements, they
> are introductory text for the rest of the section. 

Sorry, my fault. Please ignore [21] & [22] (yes, i am lazy :-)

> [23] could be
> reworded because the term "folding" is not commonly used with
> ligatures and punctuation. 

IF "continue to bashing" THEN delete [23] ENDIF;

(* why bother abt what "might"? if you are giving it as a clue, then 
   dont make it a requirement. *)

> [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.

I disagree with [25]. It may not be technical possible to have a locale
independent case folding. The example stated in [25] is an example why 
it is not possible and why we might not want to have one.

As for complience with [1] ("any system anywhere"), we have [26] and [27] to
ensure [1] is not violated. (Well, so long you have IDN-capable server
responsing consistently to the same request from any system anywhere, then it
meets [1]).

[28] is one of the toughest requirement...but not impossible. I am more
inclined to leave this in because caching servers should be transparent and
not act smart. A caching server must not break under IDN. I suggest rewording
it to the effect that the caching server should be transparent to IDN queries
and answer, doing its job on only to caching.

[29] remove pls. it actually is more a design then requirement.

[30] actually is not a bad idea...from design perspective. but yea, probably
not suitable in requirement doc.

> >Lastly, take a look at the number of RFCs we need to review.
> 
> Yup, it's a big number.

I am sceptical of the correctness tho. RFC821 is not affected is strange.

Should we do some reorganisation here so we can say "Okay, here is the
Standards RFC we *MUST NOT* break at all cost, here are the Standard RFCs we
may break..."

I am glad I am not going to do the next editing of Requirement I-D. Thanks
Zita! :-)

-James Seng