Subject: Re: [iucg] Disallowing code points

From: JFC Morfin <[email-masked]>
Date: Fri, 17 Jul 2009 00:14:00 +0200

At 13:42 16/07/2009, Vint Cerf wrote:
>The problem we foresee is that not all registry operators (remember 
>this is not just at top or second level but all through the 
>hierarchy) will show the same diligence. So  the most troubling 
>cases can be excluded by protocol.

The Charter says:
>The WG will stop work and recommend that a new charter be generated 
>if it concludes that any of the following are necessary to meet its 
>goals: (iii) A change to the basic approach taken in the design team 
>documents (Namely: independence from Unicode version and elimination 
>of character mapping in the protocol)

DISALLOWing being a "mapping to nil", here voluntarily included in 
the protocol, I hereby formally request that this WG stops all work 
and a new charter is subsequently generated.

However, as expressed in my mail sent yesterday, I fully realize that 
we are currently in the process of a coup by Unicode members. They 
are simply trying to force a new extension of their "globalization" 
doctrine layer violation (cf. attached note). They actually 
maneuvered just as we had foresaw, including utilizing us. The 
alternative they propose is:

(1) either the IETF will accept their control over the Internet 
linguistic architecture
(2) or they will claim that some people, like myself and IUCG@IETF 
members, are delaying the "overwhelming consensus" that they have 
identified, and in turn make topics of the future, such as the sex of 
the glyphs, a priority. As a result, they have been forced to proceed 
independently.

This is exactly why I will not appeal now against a negative or 
non-response from you: I prefer the regular IETF/LC to apply first. 
I, therefore, shall leave them with the responsibility to modify the 
Internet architecture as well as to introduce constraints in favor of 
a business interest group vs. the rest of the world languages, 
cultures, and nations. However, I will quote this mail in my appeal 
should the IETF/LC fail to protect the Internet neutrality the 
WG-IDNABIS Charter adequately protects. (May I remind you that I will 
not participate to the WG/LC and to the IETF due to other maneuvers 
of the same influence group, in the same lengthy opposition they have 
to the people' interests I try to defend). As far as I am concerned, 
when back from vacations, I will continue to support the IUCG, so it 
may proceed with its user documentation of the way the existing 
Internet architecture does address the "multilingualization" they 
need, in an adequate, open, cross-technology, presentation layer 
based, off-the-shelf, neutral, pollution free, and semantic 
addressing ready manner (cf. attached note). Our alternative is 
outside of their trap.

Actually, I have to thank the Unicode consortium members for having 
gallantly answered the challenge that I forced them into. They have 
far superior knowledge in the Unicode area compared to simple users 
such as us on that issue. We had to force them to document, from the 
horse's mouth, as to "why we were wrong and why they were right", and 
who was really concerned politically and why. We also needed their 
tables to be conveniently documented. We would never have obtained 
otherwise such precious material for ensuring that the Internet's 
existing possibilities would permit the support of 
multilingualization as we know now it does.

jfc

For the convenience of the readers, the context is as follows:

1. There is a linguistic (semiotic) support pile wherein:

- Universalization consists in the neutral, equal, and technical 
support of every language, script, orthotypography (the way in which 
a culture will semantically interpret the way something is written) 
and quoting capacity of other languages, i.e. every existing language 
entity is fully supported and understood. Universalization is today 
commonly obtained through the use of metaconcepts being numerically 
transcoded. Further work in that area belongs to the semantic 
facilitation technologies.

- Multilingualization is the architectural approach that permits 
universalization through, for example, the globalization (cf. below) 
of every language. Its simplest support is provided by the 
presentation layer. As in all network architecture, the Internet 
includes a presentation layer. However, up to now its exploration and 
documentation were limited.

- Globalization is a method that is documented by Unicode that 
enables the reduction of the linguistic barriers between a given 
language and other natural languages. It involves (to this day):

--- the internationalization of the media by including the signs of 
every script (ex. Unicode). The NFC is a reduction of the Unicode 
list that can be utilized via the Internet. What is being discussed 
today is to attain a further reduction for the Internet namespace.
--- the localization of the other end, through the use of "locale" files.
--- the langtagging (permitting language filtering) of the content 
for the application's benefit.

2. The CSoC

It so happens that the Unicode members seem to also benefit from a 
centralizing set of chances (CSoC) that could defeat the distributed 
nature of the world and of the Internet, and in turn sterilize the 
tremendous innovation capacity of the Internet presentation layer. 
This would be great for the present form of the Internet economy and 
governance that they dominate or participate in (stakeholders), which 
have not been properly prepared to cope with the impact of the 
activation of the presentation layer. This is why they are striving 
for innovation moratoria that they like to call the "status quo", in 
spite of the detriment that it represents for all the people.

A technical, business, and political status quo is permitted by the 
CSoC. By luck, the CSoC seems to result from porting globalization 
tasks within the multilingualization layer, something ASCII users 
fond convenient and with e-business favorable consequences. This 
layer violation limits the multilingualization layer to a single 
globalization occurrence: in this case, this is the ASCII English 
language globalization presentation.

This is technically an exceedingly unstable layer violation because 
it only rests on the subjective user acceptation to limit his/her 
Internet usage due to a misunderstanding. However, unexpectedly the 
CSoC happens to technically, commercially, and politically influence 
those who design, use, and manage the Internet in favor of such an 
auto-limitation. In particular, its constraints result in violations 
of the Internet neutrality that might make more difficult a 
deployment of the presentation layer (some 63 character DNS labels 
will be mapped to others, or to nil, upon the sole IETF engineering 
authority). This would equate to the machines and engineers (of some 
major corporations) to prevail on all the people of the world and 
their languages and culture. This is purely bad luck.

3. Interplus

Interplus comprises a two (interapplication and pseudo-network) layer 
transparent "post-wire" continuation (interplug) of the network on 
the user side. It completes the Internet architecture on an edge to 
edge basis (the network ends on the users side), in which now every 
user has an intelligent syste. This was not the case in 1983 when the 
Internet and DNS began.

The Interplus (interplugged layers on the user side system) includes 
a double interapplication networking capacity (through the Internet 
or through OPES [open pluggable edge services(*)] overlays) and an 
unlimited capacity for network interrelated services applications. (*) RFC

One of these services is to support presentations, i.e. the appearing 
change of the network to a qualified externet (an external network 
look alike within the Internet). The qualifications can include 
linguistic networks (the default being the English ASCII version), 
encryption, the support of other codes than Unicode or algorithms 
than punycode, etc. Presentations can be identified through label 
headers, (such as "xn--" for IDNA), TLD (as in the ".fra" 
experiment), classes, or a mix of them. Presentations are transparent 
to applications.

Another service is the support of the Domain Names Pile. This is a 
smart extension of the Host.txt possibility. The user name space can 
fully support the orthotypography of every language and trademarks 
through User/Universal Domain Names (UDN). UDNs will first be 
converted into Application Domain Names (ADNs) in order to relate 
with applications (such as Skype, authentication, payment services, 
etc.). If needed, they will in turn be converted into regular Domain 
Names (for example, through punycode). UDNs are independent from the 
Internet and can be used for application, TV, process resolution, IA, 
etc. As far as the Internet is concerned, IDNs (Internet Domain 
Names), as accepted and resolved by the DNS, are the reference. This 
reference should become universal and be read as based upon the 0-Z 
numbering set as well as the "." and "-" strong and weak separators.

(*)
RFC3238 IAB Architectural and Policy Considerations for Open 
Pluggable Edge Services
RFC3752 Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios
RFC3836 Requirements for Open Pluggable Edge Services (OPES) Callout Protocols
RFC3835 An Architecture for Open Pluggable Edge Services (OPES)
RFC3837 Security Threats and Risks for Open Pluggable Edge Services (OPES)
RFC3838 Policy, Authorization, and Enforcement Requirements of the 
Open Pluggable Edge Services (OPES)
RFC3897 Open Pluggable Edge Services (OPES) Entities and End Points 
Communication
RFC3914 Open Pluggable Edge Services (OPES) Treatment of IAB Considerations
RFC4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core
RFC4236 HTTP Adaptation with Open Pluggable Edge Services (OPES)
RFC4496 Open Pluggable Edge Services (OPES) SMTP Use Cases
RFC4902 Integrity, Privacy, and Security in Open Pluggable Edge 
Services (OPES) for SMTP

---

From: JFC Morfin <[email-masked]>
Date: Fri, 17 Jul 2009 04:04:23 +0200

Lisa, John,
I agree with Shawn Steel, let call a cat a cat.  There are too many 
words being used without considering their whole implications. This 
is like just thinking over details instead of also taking care of the 
whole picture. I can't and I do not think it can be productive, 
moreover in a reticular system like the Internet?

1. When a character is DISALLOWED this means that one way or another 
if it used something is going to be discarded, i.e. that "something" 
is mapped to nil. The "something" may be a single code point or the 
whole domain name, or something in between - the application decides. 
The consequence is the same: loss of information and typographic 
bandwidth reduction.

2. I consider "protocol level" as a fundamental point indeed (I do 
not think the IESG and IAB use nearly meaningless phrases in a 
Charter, moreover when issuing strict conditions). If the Charter 
says "elimination of character mapping in the protocol" this may only 
mean one thing. That thing - as we understood it, and the reason we 
are waiting for Vint's plan to complete - is well documented in Pete 
Draft: the mapping is to happen outside of the protocol, i.e. not on 
the wire. Because what is involved is outside of the network control 
and of the IETF network territory. It is users' usage operation territory.

This clearly translates in Pete's I_D:

>This document describes the operations that can be

First fundamental point: there is no MUST, this is consistent with 
the rest of the position. The only MUST is to be acceptable to the DNS.

>applied to user input in order to get it into a form acceptable by 
>the Internationalized Domain Names in Applications (IDNA) protocol 
>[I-D.ietf-idnabis-protocol]. The document describes the underlying 
>architectural principles (in section 2 and the general 
>implementation procedure (in section 3).

I class Patrick's document among the underlying architectural 
principles the WG is to define that "can be applied to user input" 
(meaning by the application). This is a BCP not a Standard.

>It should be noted that this document does not specify the behavior 
>of a protocol that appears "on the wire".

This conforms to the Charter. Character mapping of any kind MUST not 
appear on the wire, but off the wire.

>It describes an operation that is to be applied to user input in 
>order to prepare that user input for use in an "on the network" protocol.

All this clearly describe something which is outside the "on the 
network" protocol.

>  As unusual as this may be for an IETF protocol document, it is a 
> necessary operation to maintain interoperability.

The text underlines that it is unusual and qualifies what is not part 
of the protocol as an operation. We have widely published that we are 
in agreement with the Charter and with this text.

3. The coup consists in trying to obtain URL indexing stability in 
invading and annexing that territory, my/our territory. And then 
starting rulling it, through MUSTs where interoperability calls for 
negociation based upon SHOULDs. If I want to make Tatweel resolve the 
IETF site, I just have to use the 1972 host.txt service, making the 
Tatweel code-point correspond to the IETF IP. What ever the way I can 
enter a tatweel and punycode it, it will work. If I try the same 
under IDNA2008, my entry will be mapped to nil and nothing will 
happen. I do not really call this innovation and progress in 37 years 
:-) Worse, I might also name it an alias/domain name conflict.

Gee! I am on vacations !

jfc

At 00:44 17/07/2009, Lisa Dusseault wrote:
>1.  I will wait until the WG *concludes* that it needs to take a 
>different approach than that described in its charter.  Explorations 
>of different approaches are not contrary to the charter (although 
>the chair may rule such explorations out of scope and/or decide that 
>the WG came to consensus not to follow the different approach).
>
>2. I don't consider DISALLOWED to be a mapping to nil at all.  There 
>is no requirement for clients to map DISALLOWED characters to nil 
>and then request a domain -- a client could reject a string with 
>DISALLOWED characters.  Thus, even if the WG concludes to have 
>DISALLOWED characters, that does not depart from the charter- it was 
>very clear when the charter was written that some character classes 
>were to be DISALLOWED.
>
>In a similar light although this is a little off-topic, I would ask 
>you to relook at how people are using the phrase "at the protocol 
>level".  Personally, I think it's nearly a meaningless phrase, and 
>I'm disappointed that so many arguments are focusing on whether 
>mappings are happening at the protocol level or not.  But to the 
>extent that it has a meaning, I think your interpretation is not 
>quite the common one.  Suggesting to user interface implementations 
>that they could offer alternatives to disallowed characters, to help 
>the user find the site they are looking for, is about as far from 
>"at the protocol level' as you can get.

---

From: JFC Morfin <[email-masked]>
Date: Fri, 17 Jul 2009 04:10:13 +0200

I forgot a point.

At 00:44 17/07/2009, Lisa Dusseault wrote:
>Suggesting to user interface implementations that they could offer 
>alternatives to disallowed characters, to help the user find the 
>site they are looking for, is about as far from "at the protocol 
>level' as you can get.

Yes. But "suggesting" is not carried in using MUSTs (while SHOULD is 
acceptabe). This is why I am OK with everything that has no other 
MUST than DNS respect and resolvability. Because the user may want to 
use tatweel. It is also illusory to use a MUST: how are you going to 
enforce it?
jfc

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 16 Jul 2009 15:44:20 -0700

Hi,

I've CC'ed Vint on this response to your request to have the WG recharter.

I'm very aware of the charter text that requires the WG to recharter, and
I'm keeping an eye on that.  I will certainly press the WG to modify its
charter if it concludes that a different approach from that described in the
charter.

However, I am interpreting some things in a somewhat different light than
you.

1.  I will wait until the WG *concludes* that it needs to take a different
approach than that described in its charter.  Explorations of different
approaches are not contrary to the charter (although the chair may rule such
explorations out of scope and/or decide that the WG came to consensus not to
follow the different approach).

2. I don't consider DISALLOWED to be a mapping to nil at all.  There is no
requirement for clients to map DISALLOWED characters to nil and then request
a domain -- a client could reject a string with DISALLOWED characters.
Thus, even if the WG concludes to have DISALLOWED characters, that does not
depart from the charter- it was very clear when the charter was written that
some character classes were to be DISALLOWED.

In a similar light although this is a little off-topic, I would ask you to
relook at how people are using the phrase "at the protocol level".
Personally, I think it's nearly a meaningless phrase, and I'm disappointed
that so many arguments are focusing on whether mappings are happening at the
protocol level or not.  But to the extent that it has a meaning, I think
your interpretation is not quite the common one.  Suggesting to user
interface implementations that they could offer alternatives to disallowed
characters, to help the user find the site they are looking for, is about as
far from "at the protocol level' as you can get.

Thank-you,
Lisa Dusseault

On Thu, Jul 16, 2009 at 3:14 PM, JFC Morfin <[email-masked]> wrote:

>  *At 13:42 16/07/2009, Vint Cerf wrote:
> *
>
> The problem we foresee is that not all registry operators (remember this is
> not just at top or second level but all through the hierarchy) will show the
> same diligence. *So  the most troubling cases can be excluded by protocol.
> *
>
>
> *The Charter says:
>
> * if it concludes that any of the following are necessary to meet its
> documents (Namely: independence from Unicode version and *elimination of
> character mapping in the protocol*)
>
> DISALLOWing being a "mapping to nil", here voluntarily included in the
> protocol,* I hereby formally request that this WG stops all work and a new
> charter is subsequently generated.*
>
>
> *However,* as expressed in my mail sent yesterday, I fully realize that we
> are currently in the process of a coup by Unicode members. They are simply
> trying to force a new extension of their "globalization" doctrine layer
> violation (cf. attached note). They actually maneuvered just as we had
> foresaw, including utilizing us. The alternative they propose is:
>
> (1) either the IETF will accept their control over the Internet linguistic
> architecture
> (2) or they will claim that some people, like myself and IUCG@IETFmembers, are delaying the "overwhelming consensus" that they have
> identified, and in turn make topics of the future, such as the sex of the
> glyphs, a priority. As a result, they have been forced to proceed
> independently.
>
> non-response from you: I prefer the regular IETF/LC to apply first. I,
> therefore, shall leave them with the responsibility to modify the Internet
> architecture as well as *to introduce constraints in favor of a business
> interest group vs. the rest of the world languages, cultures, and nations*.
> However, I will quote this mail in my appeal should the IETF/LC fail to
> protect the Internet neutrality the WG-IDNABIS Charter adequately protects.
> (May I remind you that I will not participate to the WG/LC and to the IETF
> due to other maneuvers of the same influence group, in the same lengthy
> opposition they have to the people' interests I try to defend). As far as I
> am concerned, when back from vacations, I will continue to support the IUCG,
> so it may proceed with its user documentation of the way the existing
> Internet architecture does address the "multilingualization" they need, in
> an adequate, open, cross-technology, presentation layer based,
> off-the-shelf, neutral, pollution free, and semantic addressing ready manner
> (cf. attached note). Our alternative is outside of their trap.
>
> Actually,* I have to thank the Unicode consortium members *for having
> gallantly answered the challenge that I forced them into. They have far
> superior knowledge in the Unicode area compared to simple users such as us
> on that issue. We had to force them to document, from the horse's mouth, as
> to "why we were wrong and why they were right", and who was really concerned
> politically and why. We also needed their tables to be conveniently
> documented. We would never have obtained otherwise such precious material
> for ensuring that the Internet’s existing possibilities would permit the
> support of multilingualization as we know now it does.
>
> jfc
>
>
>
> *1. There is a linguistic (semiotic) support pile wherein*:
>
> - *Universalization* consists in the neutral, equal, and technical support
> of every language, script, orthotypography (the way in which a culture will
> semantically interpret the way something is written) and quoting capacity of
> other languages, i.e. every existing language entity is fully supported and
> understood. Universalization is today commonly obtained through the use of
> metaconcepts being numerically transcoded. Further work in that area belongs
> to the semantic facilitation technologies.
>
> *- Multilingualization* is the architectural approach that permits
> universalization through, for example, the globalization (cf. below) of
> every language. Its simplest support is provided by the presentation layer.
> As in all network architecture, the Internet includes a presentation layer.
> However, up to now its exploration and documentation were limited.
>
> - *Globalization* is a method that is documented by Unicode that enables
> the reduction of the linguistic barriers between a given language and other
> natural languages. It involves (to this day):
>
> --- the *internationalization *of the media by including the signs of
> every script (ex. Unicode). The NFC is a reduction of the Unicode list that
> can be utilized via the Internet. What is being discussed today is to attain
> a further reduction for the Internet namespace.
> --- the *localization *of the other end, through the use of "locale"
> files.
> --- the *langtagging *(permitting language filtering) of the content for
> the application’s benefit.
>
>
> *2. The CSoC
>
> *It so happens that the Unicode members seem to also benefit from a *
> centralizing* set of chances (*CSoC*) that could defeat the *distributed *nature
> of the world and of the Internet, and in turn sterilize the tremendous
> innovation capacity of the Internet presentation layer. This would be great
> for the present form of the Internet economy and governance that they
> dominate or participate in (stakeholders), which have not been properly
> prepared to cope with the impact of the activation of the presentation
> layer. This is why they are striving for innovation moratoria that they like
> to call the "status quo", in spite of the detriment that it represents for
> all the people.
>
> A technical, business, and political status quo is permitted by the CSoC.
> By luck, the CSoC seems to result from porting globalization tasks within
> the multilingualization layer, something ASCII users fond convenient and
> with e-business favorable consequences. This layer violation limits the
> multilingualization layer to a single globalization occurrence: in this
> case, this is the ASCII English language globalization presentation.
>
> This is technically an exceedingly unstable layer violation because it only
> rests on the subjective user acceptation to limit his/her Internet usage due
> to a misunderstanding. However, unexpectedly the CSoC happens to
> technically, commercially, and politically influence those who design, use,
> and manage the Internet in favor of such an auto-limitation. In particular,
> its constraints result in violations of the Internet neutrality that might
> make more difficult a deployment of the presentation layer (some 63
> character DNS labels will be mapped to others, or to nil, upon the sole IETF
> engineering authority). This would equate to the machines and engineers (of
> some major corporations) to prevail on all the people of the world and their
> languages and culture. This is purely bad luck.
>
>
> *3. Interplus
> *
> transparent "post-wire" continuation (interplug) of the network on the user
> side. It completes the Internet architecture on an edge to edge basis (the
> network ends on the users side), in which now every user has an intelligent
> syste. This was not the case in 1983 when the Internet and DNS began.
>
> The Interplus (interplugged layers on the user side system) includes a
> double interapplication networking capacity (through the Internet or through
> OPES [open pluggable edge services(*)] overlays) and an unlimited capacity
> for network interrelated services applications. (*) RFC
>
> One of these services is to support* presentations*, i.e. the appearing
> change of the network to a qualified externet (an external network look
> alike within the Internet). The qualifications can include linguistic
> networks (the default being the English ASCII version), encryption, the
> support of other codes than Unicode or algorithms than punycode, etc.
> Presentations can be identified through label headers, (such as "xn--" for
> IDNA), TLD (as in the ".fra" experiment), classes, or a mix of them.
> Presentations are transparent to applications.
>
> Another service is the support of the *Domain Names Pile*. This is a smart
> extension of the Host.txt possibility. The user name space can fully support
> the orthotypography of every language and trademarks through User/Universal
> Domain Names (UDN). UDNs will first be converted into Application Domain
> Names (ADNs) in order to relate with applications (such as Skype,
> authentication, payment services, etc.). If needed, they will in turn be
> converted into regular Domain Names (for example, through punycode). UDNs
> are independent from the Internet and can be used for application, TV,
> process resolution, IA, etc. As far as the Internet is concerned, IDNs
> (Internet Domain Names), as accepted and resolved by the DNS, are the
> reference. This reference should become universal and be read as based upon
> the 0-Z numbering set as well as the "." and "-" strong and weak separators.
>
>
>
> (*)
> RFC3238 IAB Architectural and Policy Considerations for Open Pluggable Edge
> Services
> RFC3838 Policy, Authorization, and Enforcement Requirements of the Open
> Pluggable Edge Services (OPES)
> RFC4902 Integrity, Privacy, and Security in Open Pluggable Edge Services
> (OPES) for SMTP
>
>
>
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 16 Jul 2009 18:59:05 -0400

--On Friday, July 17, 2009 00:14 +0200 JFC Morfin
<[email-masked]> wrote:

> DISALLOWing being a "mapping to nil", here voluntarily
> included in the protocol, I hereby formally request that this
> WG stops all work and a new charter is subsequently generated.

Disallowing is _not_ "mapping to nil".  It is a simple
prohibition of the use of the code point (I'm reluctant to say
"character" here) in DNS labels.  While there were some mappings
to nil in IDNA2003, we have eliminated all of them (despite a
few objections from some of the Unicode folks) in IDNA2008.  I
believe any attempt to revisit those decisions will meet very
strong resistance from the WG (or at least from me).

It would help with this process if you would read the documents
carefully enough to know what you are talking about.

regards,
    john

---

From: JFC Morfin <[email-masked]>
Date: Fri, 17 Jul 2009 14:06:02 +0200

At 05:36 17/07/2009, John C Klensin wrote:
>--On Friday, July 17, 2009 04:04 +0200 JFC Morfin
> > I agree with Shawn Steel, let call a cat a cat.  There are too
> > many words being used without considering their whole
> > implications. This is like just thinking over details instead
> > of also taking care of the whole picture. I can't and I do not
> > think it can be productive, moreover in a reticular system
> > like the Internet?
>
>I think it is precisely the whole picture that we are concerned
>about.  The whole, global identifier, picture, not one country
>or language group at a time.

Dear John,
from 40 years experience in navy, communications and policy this is 
the fundamental issue the world has with the american culture and 
language. It is not an opposition. It is a built-in misunderstanding. 
The understanding of the string "global" is opposed. This is the core 
of the IDNA issue.

In American English "global" means the entire Globe. In British 
English, French and other languages "global" means all the parts of 
the same Globe. For example, someone like José Bové fiercely stands 
for smart globalisation against imposed globalization. Globalisation 
is a fact that the Internet technically supports, globalization 
("mondialisme" in French) is a policy using the Internet to 
propagate, in particular by standardisation infuence (cf. RFC 3935).

There is an inner contradiction in your sentence that we meet here. 
The intended proposition is unilateral while reality is diverse, i.e. 
we care about the sum of all the countries, languages, and people. 
This translates very simply: the ISOC motto is user centric. The WSIS 
objective is people centric. Technical totalitarism is the difference 
: users go by the user guide. People go by their informed free-will. 
Pete's document is unilateral and as such it can only apply to one 
single presentation. However, it is flexible enough (SHOULDs and 
MAYs) to accomodate a legitimate diversity. So, it is a reasonable 
compromise against both rigidity and laxism.

> > 1. When a character is DISALLOWED this means that one way or
> > another if it used something is going to be discarded, i.e.
> > that "something" is mapped to nil. The "something" may be a
> > single code point or the whole domain name, or something in
> > between - the application decides. The consequence is the
> > same: loss of information and typographic bandwidth reduction.
>
>Again, no.  If a character is DISALLOWED, then the string that
>it contains is prohibited at a label, is not looked up, and, I
>hope results in a message to the user that it is invalid.  That
>has nothing to do with discarding all or part of the string and
>then looking something else (or a subset) up.  The latter would
>be a clear violation of the protocol.

I do not refer to any protocol. I refer to the relation between the 
user and the proposed system. I refer also to the way I would/have 
implement the code and the answered error message.  Let keep it 
simple in using a common metric to the people/process involved. This 
is what I call detail vs. the global diversity of the whole picture.

> > 2. I consider "protocol level" as a fundamental point indeed
> > (I do not think the IESG and IAB use nearly meaningless
> > phrases in a Charter, moreover when issuing strict
> > conditions). If the Charter says "elimination of character
> > mapping in the protocol" this may only mean one thing. That
> > thing - as we understood it, and the reason we are waiting for
> > Vint's plan to complete - is well documented in Pete Draft:
> > the mapping is to happen outside of the protocol, i.e. not on
> > the wire. Because what is involved is outside of the network
> > control and of the IETF network territory. It is users' usage
> > operation territory.
>
>Yes.  We actually agree about that.  But it has nothing to do
>with which characters are DISALLOWED, which the mapping document
>carefully does not touch.

It has to do with who (IETF or User) disallows and under which 
constraint/advise (SHOULD or MUST).

> > First fundamental point: there is no MUST, this is consistent
> > with the rest of the position. The only MUST is to be
> > acceptable to the DNS.
>
>No.  The MUST is to be consistent with the core IDNA2008 specs,
>which include consistency with the DNS.  And that is exactly
>what the rest of the sentence says.

OK: what are the other constraints made necessary by the IDNA2008 
Mapping document? Except IDNA2003 I do not discuss.

> >> applied to user input in order to get it into a form
> >> acceptable by  the Internationalized Domain Names in
> >> Applications (IDNA) protocol  [I-D.ietf-idnabis-protocol].
> >> The document describes the underlying  architectural
> >> principles (in section 2 and the general  implementation
> >> procedure (in section 3).
> >
> > principles the WG is to define that "can be applied to user
> > input" (meaning by the application). This is a BCP not a
> > Standard.
>
>If, by "Patrick's (sic) document" you mean
>draft-ietf-idnabis-tables, it is referenced normatively from
>Protocol and is a core part of the Standards-Track IDNA2008
>specification, not a BCP.

As long as the mapping document does not make it a MUST it can 
legitimately be optionnal at User's decision. In such a case the User 
will use it as a Unicode related BCP. Actually, as I say it is an NFC 
restriction, NFC being itself a Unicode restriction. At the end of 
the day we will obtain a more restricted version of the visually 
based alternative to Unicode I wanted.

> >> It should be noted that this document does not specify the
> >> behavior  of a protocol that appears "on the wire".
> >
> > This conforms to the Charter. Character mapping of any kind
> > MUST not appear on the wire, but off the wire.
>
>Sure.  But, strictly speaking, IDNA does not appear on the wire.
>Only A-labels do.  That has been the source of a lot of
>confusion.  Note that the IRI document, which is well outside
>the WG's scope, does refer to IRIs as protocol elements, which
>pushes them into the "on the wire" category, including their IDN
>components.

This is a topology closure problem. You can define the end of a 
protocol where you want, including using a virtual wire. A protocol 
is univesal. Here we deal with the edges (network and user sides), 
i.e. with a global issue. In other words, the border between the 
network and the user is not a line, it is thick. This thickness is 
the Interplus. It can be supported via OPES if to keep with IETF 
documentation. Actually networked OPES I call ONES for a few decades 
(Open Network Extended Services). My Tymnet 1985 department.

> >> It describes an operation that is to be applied to user input
> >> in  order to prepare that user input for use in an "on the
> >> network" protocol.
> >
> > All this clearly describe something which is outside the "on
> > the network" protocol.
>
>Yes.  So?
>
> >>  As unusual as this may be for an IETF protocol document, it
> >>  is a  necessary operation to maintain interoperability.
> >
> > The text underlines that it is unusual and qualifies what is
> > not part of the protocol as an operation. We have widely
> > published that we are in agreement with the Charter and with
> > this text.
>
>Ok.  So we are arguing about what?
>
> > 3. The coup consists in trying to obtain URL indexing
> > stability in invading and annexing that territory, my/our
> > territory. And then starting rulling it, through MUSTs where
> > interoperability calls for negociation based upon SHOULDs. If
> > I want to make Tatweel resolve the IETF site, I just have to
> > use the 1972 host.txt service, making the Tatweel code-point
> > correspond to the IETF IP. What ever the way I can enter a
> > tatweel and punycode it, it will work. If I try the same under
> > IDNA2008, my entry will be mapped to nil and nothing will
> > happen. I do not really call this innovation and progress in
> > 37 years :-) Worse, I might also name it an alias/domain name
> > conflict.
>
>There is no coup and the above is either a  misinterpretation or
>outside the WG's scope.

It is out the WG technical scope. By nature, and because the Charter 
says so. This is why we do not support the coup and support the 
Charter. Actually I do not bother about WG scopes, I bother about 
what hurts me. I bother about Charters only because I consider it as 
a contract every party said it will respect.

>URIs are prohibited from containing
>non-ASCII domain names -- I believe globally although there are
>some factions who believe that such names can be included in
>%-escaped UTF-8 in those fields.

In my daily life I never meet an URI, but would I, I would be hurt 
the same in understanding what they may refer to if the 
orthotypography is wrong.

>And you can't use the 1972 Hosts.TXT service because it was shut
>down long ago.  More important, it was strictly limited
>--technically and administratively-- to ASCII letters, digits,
>and hyphens, so there is no way to express a Tatweel in those
>tables.

I keep using "http://nuts" to access ICANN's site. Hosts.txt works 
perfeclty well with punycoded entries.

>In IDNA2008, you simply cannot express Tatweel in a label so, in
>that narrow sense, the behavior under the Hosttable rules and
>that under IDNA2008 is identical.

For the time being I do not know what IDNA2008 is going to be. But I 
am pretty sure that Pouzin's keyword service can support tatweel.

> > Gee! I am on vacations !
>
>Yeah.  And I'm trying to retire.

I am suppose to retire on oct. 7th (in France they become less rigid, 
so I am creating a new business)
Best
jfc

> >...
> >> 2. I don't consider DISALLOWED to be a mapping to nil at all.
> >> There  is no requirement for clients to map DISALLOWED
> >> characters to nil  and then request a domain -- a client
> >> could reject a string with  DISALLOWED characters.
>
>Indeed, I think the client is required to do so and that simply
>mapping a DISALLOWED character to nothing would be a violation
>of the specification.  Except for those characters that
>IDNA2003 _required_ by mapped to nothing, that is also true of
>IDNA2003.  There is no provision in either for a conforming
>implement to drop prohibited characters and look up the rest of
>the label.

NB. the first thing a parser should do is to look for the disallowed 
code points and reject the entry (with an error message or a log 
entry), the same action as if the entry was empty. You can ask for 
more a subtle operation through a SHOULD. You cannot oblige to it 
(via a MUST) as this has no impact on the wire.

---

From: John C Klensin <[email-masked]>
Date: Thu, 16 Jul 2009 23:36:26 -0400

Yes.  So?

 

outside the WG's scope.  URIs are prohibited from containing

regards,
   john