[idn] Re: Proposed Edits Re: alpha v0.2

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

I am going thru all the mails now preparing for v0.4. 

"J. William Semich" wrote:
> >The same name resolution request should generate the same response,
> 
> [This may not be technically possible if clients do not use a standardized
> "charset" for queries - do we want to be this specific? I would delete this
> sentence.]

I think the same name resolution requests should generate the same response is
one of the important requirement to ensure we are not breaking the basic
principle. In fact, I rate this important enough to be a "must" but a "should"
is fairer. 

Note that this requirment is also inline with "It must continue to allow any
system anywhere to resolve any domain name."

> >[Implementors may proposal modification to DNS protocol [RFC1035] and
> >other related work undertaken by [DNSEXT] WG. However, these changes
> >should be as minimal as possible and it must be approved by the DNSEXT
> >WG.]
> 
> [I would propose to delete the paragraph above and replace it with:
> 
> It is expected that changes to the DNS protocols [RFC1035 and others] will
> be required in order to implement IDN -BS].

Essentially, you are changing the "may" requirement to a "should". I think the
conseqences of this is huge. The original intention is "may but should not"
but changing it "should" will send a signal to all protocol proposal out there
that they "should" proposal a change in RFC1034, or at least try.

Are we prepare to do this? What would the DNSEXT WG think?

> >IDN should not make any assumptions where in the domain name that I18N
> >might appear. In other words, it should not differentiate between any
> >part of a domain name as it may impose a restrict on future I18N
> >effort.
> 
> [I don't think I agree with the above sentence either. the whole mixed
> charset argument...-BS]

Care to explain further? This has nothing to do with multiple character set or
encodings etc. It is just a general statment which state that we should not
assumed that I18C will not appear in any level of the domain or part of. 

> [a] domain name to use a single script would immediately restrict
> multinational
> >organisation.
> 
> [I am a bit confused by the language above. This is  a technical standard,
> not a cultural one, right? So what word instead of "culture" or "cultural"
> would better achieve the intention of this sentence? My preference would be
> to delete the whole sentence -BS]

localized?

> >IDN must be able to handle localized requirement of different languages.
> >For example, IDN must be able to handle right-to-left writing order of
> >Arabic.
> 
> [I do not agree with the above sentence - I think it has already been
> discussed. Can we delete it?  -- BS]

Sorry, are you saying we should not even consider the localized requirement of
the IDN? I did not remember anyone disagreed with this. Perhaps I missed that
mail so can you please forward me the mail which make that conclusion.

> In addition, IDN must be able to provide the same DNS resources using
> internationalized text as it currently provides using ASCII text. - BS]

Will do. But "must" is not a good requirement. I think this is agreed as a
"may" requirement, ie "we discussed it before and considered it as non-issue
for IDN" as described by Harald.

> >IDN capable resolver or server should not generate any more traffic
> >than a non IDN capable resolver or server.
> 
> [I would delete the above sentence. It is impossible to quantify "any more
> traffic" -- BS]

Agreed that we cannot quantify "more" traffic. But before we remove that, can
someone try repharse this?

> >2.5 Others
> >
> >The DNS protocol should remain deterministic. No DNS element (resolver,
> >server or zonefile) should be required to do guess work.
> 
> [I would delete the above. Unless clients, resolvers and servers all use a
> single standard for the query, *something* will have to do guess work.
> There are too many variables -- BS]

this is a second request to remove this altho the first reason was that we can
presume the protocol must be deterministic in order to satisfy "same answer to
any query from any server anywhere".

i will drop this out of v0.4 anyway.

Thanks Bill.

-James Seng