[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Requirements I-D
- To: James Seng <firstname.lastname@example.org>
- Subject: Re: [idn] Requirements I-D
- From: Paul Hoffman / IMC <email@example.com>
- Date: Mon, 15 May 2000 07:35:38 -0700
- Cc: firstname.lastname@example.org
- Delivery-date: Mon, 15 May 2000 07:38:22 -0700
- Envelope-to: email@example.com
At 1:16 PM +0800 5/14/00, James Seng wrote:
> >  - 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  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.
> >  - 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.
> >  - Reword to say that IDN is a protocol, not an interface.
>Conflict with  - 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
Ah! I missed that part. Yup, removing  would make things clearer.
> >  - 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 sounds good.
> > , , ,  (other than the
>> folding wording), , and  seem fine as is.  should be
>> removed (and there were certainly more than 1 request to do so). 
>> should be removed because it conflicts.
>I disagree with . It may not be technical possible to have a locale
>independent case folding. The example stated in  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.
> 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.
> remove pls. it actually is more a design then requirement.
Disagree. Going back to the diagram,  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,  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
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