Bundling, mapping & merchandizing (was Re: Final Sigma (was: RE: Esszett, Final Sigma, ZWJ and ZWNJ))

[JFC Morfin]

Dear Erik and Eric,

2009/2/25 Erik van der Poel <erikv at google.com>:
>  One idea might be to reserve xn-- for the "global" mappings that are
> based on Unicode specs. Then you and other Greek script users could
> come up with a spec for the Greek script and/or language, and the
> prefix to use in that case could be gr-- or if that is politically
> sensitive, just take the "next" prefix after xn-- which would be xo--
> since 'o' comes after 'n'.
.
1. using "x0--" to "xz--" is one of the ways (probably the easiest) to
pass meta-information on the algorithm that is being used. It is
documented in the Semantic Addressing Draft that I am working on (with
xx- for private naming space, for similarity with the "x-" RFC 4646
private space). However, since we have time with the IDNA and the IPR
hiccup,I wanted :
- (1) someone else with a better understanding of the IETF point of
view to propose it. "xg--" and "xf--" could stand for Greek and
French.
- (2) to obtain (from acknowledged UNESCO and ISO expert linguists)
more information on all the semiotic cases that we might encounter.

The interest is that "xn--" as the default "extended name" flag is
only IDNA2003 compatible, and that other "x.--" can be easily filtered
by IDNA2008. This permits one to avoid more exotic solutions such as
classes or a header change. The pending question is for investigating
about how the IDNA2008 advisable filtering format (either x.-- or
x...--) is to meet all of the diverse algorithms that we might need
(it seems that we might need one per sociocultural TLD or relational
space).

Please note that "x.--" belongs to the A-label, but not to the
U-label. Therefore, there is no conflict between the domain names that
are registered along different algorithms with the same punycode.
Moreover, the same punycode can be easily registered along several
algorithms.

Actually, I consider "." as a syntaxic strong separator and "-" as a
weak separator. This is in line with the initial use of "-" and
provides a lot of flexibility. In left to right semantic addressing
(for programming language structures) this simplifies the syntax, with
the weak separator becoming "_".

2009/2/25 Eric Brunner-Williams <ebw at abenaki.wabanaki.net>:
> He and probably everyone not present at the Delhi Registry Constituency
> meeting when Edmund Chung and I urged Paul Twomey and Peter Dengate
> Thrush ("ICANN Staff" hereafter) to consider variant strings in new gTLD
> proposals so that the same user expectation could have been met and made
> transparent and costless knows that this proposal was rejected, and by
> whom. Peter and Paul responded immediately that each distinct sequence
> of code points was (a) a separate application, and (b) potentially
> awarded to separate applicants -- in their (incorrect) view, variant
> strings were just another registry operator business exploit that we
> were trying to get "for free".
>
> The real point here isn't that Peter and Paul need clue, rather that
> anyone who contributes to the IDNA mailing list on _policy_, in
> particular on registry policy, and generalizes from a very limited set
> of knowledge and experience to some general rule, could ask if their
> views are consistent with a larger body of knowledge and experience,
> rather than assert their generalization as fact.
>
> I wouldn't take it amiss if everyone were to extend their agreement to
> the proposition that variant strings for gTLD applications ought not to
> cost the registry applicant an arm and a leg each, nor result in
> separate parties, contracts and practices for two or more members of a
> set of variant strings for a particular application string. Hitting
> ICANN's greedbot that's currently demanding $185,000 per variant, plus
> $75,000 per year per variant, with a large cluebat, would be slightly
> more useful than complaining about registry greed and stupidity, which
> is where Shawn's note about "all the variants of some IDN form of
> mYdOmAiN.com", which started this thread, and the prior "doesn't scale"
> notes by others earlier in related threads, depart.
>
> The second is to comment  made by Patrick:
>
>    If we talk about domain names, lets talk about domain names. If we are
>    to talk about URIs, lets talk about URIs.
>
> I know I'm a minority of one (or more, but not a lot more) that views
> the proper scope of the Working Group to be mechanisms for extending the
> range of characters which may form valid DNS text labels from the ASCII
> LDH set. Whether DNS text labels are correctly processed by anything
> other than resolvers is outside of scope.

The other problem, which I wanted someone else to raise first, thank
you Eric, is the position of ICANN. This creates another difficult
technical problem since they behave as if they owned the world's
namespace (DNs, IDNs, URI, Semantic Addresses, language lexicology,
etc.) and, therefore, want to introduce, for commercial reasons,
otherwise meaningless constraints. Therefore, the real issue is not
only bundling and mapping but also merchandising.

I agree with Patrick in that all of these considerations should be
unbundled, so that URIs, IDNs, Semantic Addressing, IDNA, ML-DNS
should be treated separately, with the hope that merchants eventually
accept that their best interest is to address the needs of those who
pay.

jfc