[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] Canonicalization: [28] through [31]



As James noted, this is a requirements document - let's not to be so
specific that we constrain various implementations that will work. Yes, we
should specify canonicalization must happen - but not *where* it should
happen - and see how proposed implementation proposals deal with it.
Interoperability requirements are dealt with under 2.1, [1] - [10].

Proposed substitute language for [29] and [30]:

"The protocol MUST specify canonicalization. If canonicalization is done at
the server, the server should be able to recognize requests that have
already been canonicalized and should treat them as such."

-- Bill Semich

"At 07:38 AM 6/27/00 +0200, Patrik Fältström wrote:
>At 22.55 -0400 00-06-26, J. William Semich wrote:
>>At 08:48 AM 6/27/00 +0800, James Seng wrote:
>>  >I think we should leave this discussion to the proposal. I am okay with
>>Paul's
>>  >amendement, ie.
>>  >
>>  >"The protocol MUST specify canonicalization, and the canonicalization
>>  >SHOULD be done before the request enters the DNS service interface."
>>
>>
>>SHOULD is still too strong a requirement for an open approach to
>>implementation.
>
>Not at all. We need the strong language because of interoperability, 
>like Ran has so much argumented for.
>
>>Let's say:
>>
>>"The protocol MUST specify canonicalization, and the canonicalization
>>MAY be done before the request enters the DNS service interface or it MAY
>>be done at the server."
>>
>>And add:
>>
>>"If cannonicalization is done at the server, the server should be able to
>>recognize when requests have already been canonicalized and should treat
>>them as such."
>>
>>And let's see what various implementations do.
>
>That is for me not good enough. Keep the language proposed.
>
<snip>

-- Bill Semich