Re: [idn] Requirements I-D

[Paul Hoffman / IMC <phoffman@imc.org>]

At 1:16 PM +0800 5/14/00, James Seng wrote:
>  > [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?)

Right, but [8] says that the requirement is to change the user 
interaction as little as possible; it doesn't prescribe a user 
interaction. That's why I think it's good to keep it.

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

I would be perfectly happy with the first choice. Does anyone here 
feel that the eventual IDN might have multiple charsets? If so, 
speaking up now would be good.

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

Ah! I missed that part. Yup, removing [17] would make things clearer.

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

That sounds good.

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

And I disagree with that. It is quite easy to have 
locale-independence: you specify all case-folding in a single 
universal file. That might not agree with some local norms, but it 
works just fine for the universal DNS. Software that handles domain 
names might be different than software than handles other text 
processing. The same mismatch will affect things other than just 
case-folding; for example, character order will probably also be 
different in some cases.

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

That sounds fine.

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

Disagree. Going back to the diagram, [29] says "all canonicalization 
must be done before entering the big box through the DNS service 
interface". Without such a requirement, it is not clear where in the 
big box canonicalization might be done. Unless you are proposing a 
very strict structure for the mushy parts inside the large box so 
that you can say which parts handle canonicalization and which parts 
do not, [29] is needed. And I think it is way too late in the 
deployment of DNS to start saying exactly how the parts of the big 
box must be structured. It is fine to require that the IDN say 
exactly where canonicalization will happen.

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

The list looks like just a grep of RFCs that mention "domain names", 
not something that was thought through. Your suggestion seems much 
more useful. We could start with the ones in RFC 2825 and let folks 
add other ones to it.

--Paul Hoffman, Director
--Internet Mail Consortium