[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] IDN refocus, v4
> I don't want to make a big deal out of this point, but I would like to
say
> that the distinction is required for basic functionality. For example,
SRV
> entries use underscore, which is not a permitted character in nameprep
> (rightly) for use with host names, so domain names and host names have
to
> be defined individually if both are to function.
Our opinion on host vs domain name isnt really different :-). The
question is which one do we do? Or both? All are valid answer.
> Defer all display processing, but give guidance on basic elements such
as
> boundaries and illegal conditions. For example, we know that seven-bit
> domain names cannot be encoded in ACE, are harmful when provided, and
MUST
> be discarded when discovered, and this information has to be relayed
to
> other working groups.
Hmm, good point. I agree with the concept of doing so. I am not sure of
the exact mechanism to do so tho but that is what a goal is for ;) But I
do see this as the goal for the next step when we have one.
> > Define an IDN label encoding that protocols and applcations can used
to
> > store and represent i18n domain names.
>
> I see this as an opportunity to establish the consensus, which would
> facilitate finite deliverables for the WG. We can cut the overall
timeline
> down if we go through the pain once and for all. Once we can agree on
the
> objectives, arguing over deployment mechanics is a lot less stressful
> (hopefully). We really should come to terms with the objectives first,
or
> else this will remain a perpetual open issue.
Okay, then I have one more questions before (2) & (3).
Do we need more than one IDN label encoding that protocols and
applications can use to store and represent i18n domain names?
-James Seng