Valid/invalid Label

[JFC Morfin]

Dear Patrick,the main difficulty with multilingualisation is that it belongs
to a multilateral approach of the internet architecture. When it considers a
feature that seems to be foundamental to an unilateral approach, it only
consider adding a new degree of possibility. In that form of architectural
thinking more structural control by the TLD Manager must be fully
structurally interoperable with less structural control by the TLD Manager.
You see from this remark that you have two entities to consider : the
structure and the TLD Manager. The TLD Manager decides of the structural
supports it wants out of the range of possibilities offered by the
protocol.

Please note that the less a TLD Manager has structural control, the more
zone managers have control (this is decentralization): this increases the
systemic complexity of _that_ TLD, and the complexity of the whole TLD
exosystem (DNS) where other TLDs may have different system complexity. The
role of the protocol is to reduce that complexity in simplifying the inner
intelligence (how its various elements relate together) of that system. This
is the Maupertuis' least-action principle which confirms, for more than 250
years, every scientific and technical achievement.

For the time being, I feel that the least action in the IDNA case is the
variation of the second element in the "x.--" prefix. It necessary calls -
but does not impose - for the Alireza's TLD autonomy. It can also use but
does not require systematic dnslocales or new RRs. It does not interfere
with DNSSEC and fully permit virtual zones (from virtual root down to
crosslinguistic ledgers, i.e. common rules, procedures, registration,
services, etc. to zones of same linguistic background).

I hope it helps.
jfc


2009/2/28 Patrik Fältström <patrik at frobbit.se>

> Ok, I understand. Thanks.
>
>    Patrik
>
>
>
> 28 feb 2009 kl. 10.22 skrev Alireza Saleh <saleh at nic.ir>:
>
> > Yes, because I think whatever happens beyond the registered level is
> > the applicant responsibility and if he wants to create names with
> > confusion it is up to him. This argument would be also true for the
> > registries that currently having some supplementary policies for
> > bundling as these policies are also effective only at the registered
> > label with the registry.
> >
> > Alireza
> >
> > Patrik Fältström wrote:
> >> And this is why I do not understand why you propose alternative (1)
> >> that is _only_ limiting what a registry on highest levels in the
> >> tree does, and not solutions where we in protocol block what can be
> >> done at any level.
> >>
> >>   Patrik
> >>
> >>
> >>
> >> 27 feb 2009 kl. 21.23 skrev Alireza Saleh <saleh at nic.ir>:
> >>
> >>> Theoretically yes, but it is not possible to blame the registry
> >>> service
> >>> about whatever the owner of the domain wants to create under his
> >>> domain.
> >>> The current DNS topography shows it is important to keep second
> >>> level
> >>> labels safe. Consider a company owns x.com and having a legal
> >>> service
> >>> under y.x.com, is possible for that company to create another host
> >>> such
> >>> as z.x.com for phishing against y.x.com ?
> >>>
> >>> Currently many registries have some regulations under their TLD
> >>> without
> >>> having any control of the sub-domains to protect against trademarks,
> >>> confusion and etc.
> >>>
> >>> Alireza
> >>>
> >>> Andrew Sullivan wrote:
> >>>> On Fri, Feb 27, 2009 at 01:38:34PM +0330, Alireza Saleh wrote:
> >>>>
> >>>>> I think that a possible solution would be considering virtual
> >>>>> links
> >>>>> between one or some sections of Unicode and one or some TLDs.
> >>>>>
> >>>>
> >>>> I'm not convinced that "TLD" is the only important level, though.
> >>>> Surely it's entirely possible for someone to want (for instance)
> >>>> [U-label].blogspot.com.  No?
> >>>>
> >>>> A
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> Idna-update mailing list
> >>> Idna-update at alvestrand.no
> >>> http://www.alvestrand.no/mailman/listinfo/idna-update
> >>>
> >
> >
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090228/62e129be/attachment.htm