[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] canonicalization
- To: idn@ops.ietf.org
- Subject: Re: [idn] canonicalization
- From: Paul Hoffman / IMC <phoffman@imc.org>
- Date: Sat, 27 May 2000 19:57:22 -0700
- Delivery-date: Sat, 27 May 2000 19:57:43 -0700
- Envelope-to: idn-data@psg.com
At 10:04 AM +0800 5/28/00, James Seng wrote:
>Harald Tveit Alvestrand wrote:
>> - The same octets in a query MUST always return the same data
>> (modulo the DNS games we all know and love :-()
>
>I suggest not to include this as it is already described in [3].
It would be good if something along the lines of what Harald
suggested stay in the canonicalization section of the requirements.
How about:
- The canonicalization performed MUST NOT cause the data returned to
be different for the same request sent from different locations or to
different servers.
> > - A proposal SHOULD adhere as closely as possible to the Principle of
> > Least Astonhsiment
>
>Cool. Do you want to define "Principle of Least Astonishment"?
>
>How about this.
>
>- The protocol SHOULD have some form of canonicalization and folding rules
> such that equivalent names are folded into one. It is understood that
> these rules would not be 100% perfect or accurate.
Why "canonicalization and folding rules" instead of just
"canonicalization"? We don't have hard-and-fast definitions for each,
and it seems that the folding rules we have discussed so far would
easily be part of the canonicalization.
> > - A proposal MUST allow any client to interoperate correctly with any
> > server, as long as they implement the proposed protocol correctly
>
>This boils down to "The protocol MUST work." :P Can we leave this out?
The "any server" part is important. My proposal above rolls this in.
--Paul Hoffman, Director
--Internet Mail Consortium