Subject: [iucg] The "Internet PLUS" IUCG document is released

From: JFC Morfin <[email-masked]>
Date: Wed, 03 Jun 2009 00:39:26 +0200

Eventually ... I compeleted it :-) !
For your information the bilingual IUCG Draft on the Internet PLUS is 
now on http://iucg.org/wiki/Internet_PLUS. It notably extends the 
possibilities of the Internet usage without touching to the Internet 
itself. I am interested in comments before also publishing it as an 
IETF Draft.
jfc

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 04 Jun 2009 20:23:57 +0200

JFC Morfin wrote:
> now on http://iucg.org/wiki/Internet_PLUS.

(While being bilingual eases reading, it makes changes tougher...)

> It notably extends the possibilities of the Internet usage without 
> touching to the Internet itself.

Being a newcomer, I'm not shy to say I have difficulties understanding 
it. I've taken a few notes while reading it, and I paste them below, 
as feedback (format: "---" snippet-of-original-text newline comment.)

---
The Internet upper layer began with three applications (Telnet, FTP, 
and RJE). Several applications have been added

RJE is Remote Job Entry? I'd drop this, unless many readers know it.
---
The proposition of this memo is to consider a response to these needs

"these" is slightly ambiguous in such a statement.
---
The presentation layer is then understood as proceeding from the 
concept of the "prestag" of a domain name label.

"prestag" hasn't been defined yet. ("xn--" is called the "ACE prefix", 
where ACE means ASCII Compatible Encoding, in rfc3490. prestag is 
defined by example as a generalization of that concept.)
---
This is why an optional transparent addition to the TCP/IP (v4 and v6) 
protocol header is probably needed for delivering the naming 
information when the used protocol does not do it

Hm... that would conflict with the requirement that the network 
architecture must not be affected. It should be possible to add names 
on a protocol by protocol basis (as in the Server Name Indication of 
rfc4366). A generic layer to store needed extra parameters could also 
be envisaged, making that extra data available for protocols built 
upon such layer, but TCP/IPP is a misnomer if such layer can 
transparently use, say, SCTP instead of TCP, or IPv6 instead of IPv4.
---
RFC 2929 says: "At the present time, there are two categories of label 
types: data labels and compression labels."

s/2929/5395/
---
This MUST respect the DNS rules when the Internet is used as a 
network. IDNA is an example of such a respect.

I'd word the first sentence as "This MUST respect the DNS rules so 
that the Internet can be used as a network", in order to avoid readers 
wondering about what cases are allowed to break DNS rules.

As for the IDNA example, I'm not sure how generic it is. (Possibly 
unlike TATWEEL) accents in French are just part of orthography, and 
cannot be used to _accentuate_ a label, in the sense of tweaking its 
semantics. A transparent behavior similar to IDNA, where the encoded 
name is nonsensical and hence never displayed, could be achieved with 
per-user settings, and that is, IMHO, the limit of the example. BTW, 
making the only example in Arabic --or Greek, for that matter-- may 
also limit understanding somewhat ;-)
---
Network "Application" layer

This chapter gives the impression that we are talking about i18n 
mangling only. (If that were true, the term "semantic" would be a 
misnomer.)

Conceptually separating "the Internet" from the new framework being 
described is also going to generate confusion. Even if it is named 
"Internet PLUS", it doesn't make much sense to distinguish "the 
Internet" and "the PLUS" as separate parts, because Internet PLUS is 
meant to eventually be part of the Internet, and hence, at some point, 
it will be the Internet tout-court.
---
Syntax

Limiting to "." and "-" provides for a very restrictive syntax. Since 
we have converters, it would be possible to define type-rendering of 
UDNs using other ASCII characters that are not allowed in ADNs, e.g. 
parentheses as in www.example(my-binding).org, or 
john(tel).example.net --along the line of [email-masked].
---
This means that nothing, that it permits to dynamically do could, 
which in turn not be statically obtained by using "Host.txt".

That's not strictly true if part of the UDN is going to be stored at 
an intermediate layer, e.g. the virtual host name (mentioned in a 
previous comment about TCP/IPP.)

---

From: JFC Morfin <[email-masked]>
Date: Thu, 04 Jun 2009 20:49:57 +0200

Thank you for these inputs!
I am buzzy with a key answer to an RFP until 17:00 tomorrow. I will 
look into this then
Best
jfc

At 20:23 04/06/2009, Alessandro Vesely wrote:
>>For your information the bilingual IUCG Draft on the Internet PLUS 
>>is now on http://iucg.org/wiki/Internet_PLUS.
>
>Being a newcomer, I'm not shy to say I have difficulties 
>understanding it. I've taken a few notes while reading it, and I 
>paste them below, as feedback (format: "---" 
>snippet-of-original-text newline comment.)
>
>---
>"prestag" hasn't been defined yet. ("xn--" is called the "ACE 
>prefix", where ACE means ASCII Compatible Encoding, in rfc3490. 
>prestag is defined by example as a generalization of that concept.)
>---
>This is why an optional transparent addition to the TCP/IP (v4 and 
>v6) protocol header is probably needed for delivering the naming 
>architecture must not be affected. It should be possible to add 
>names on a protocol by protocol basis (as in the Server Name 
>Indication of rfc4366). A generic layer to store needed extra 
>parameters could also be envisaged, making that extra data available 
>for protocols built upon such layer, but TCP/IPP is a misnomer if 
>such layer can transparently use, say, SCTP instead of TCP, or IPv6 
>instead of IPv4.
>---
>RFC 2929 says: "At the present time, there are two categories of 
>label types: data labels and compression labels."
>
>s/2929/5395/
>---
>that the Internet can be used as a network", in order to avoid 
>readers wondering about what cases are allowed to break DNS rules.
>
>name is nonsensical and hence never displayed, could be achieved 
>with per-user settings, and that is, IMHO, the limit of the example. 
>BTW, making the only example in Arabic --or Greek, for that matter-- 
>may also limit understanding somewhat ;-)
>---
>mangling only. (If that were true, the term "semantic" would be a misnomer.)
>
>meant to eventually be part of the Internet, and hence, at some 
>point, it will be the Internet tout-court.
>---
>Syntax
>
>Limiting to "." and "-" provides for a very restrictive syntax. 
>Since we have converters, it would be possible to define 
>type-rendering of UDNs using other ASCII characters that are not 
>allowed in ADNs, e.g. parentheses as in www.example(my-binding).org, 
>or john(tel).example.net --along the line of [email-masked].
>---
>_______________________________________________
>iucg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/iucg

---

From: JFC Morfin <[email-masked]>
Date: Sun, 07 Jun 2009 04:59:12 +0200

>>(While being bilingual eases reading, it makes changes tougher...)

The IUCG is supposed to accept every language (in the hope there is 
someone to pick the relevant idea and translate). As ISO it should be 
bilingual. In fact for good writing it should also be dicussed in 
Chinese to get the three different reasoning systems.

>>Being a newcomer, I'm not shy to say I have difficulties understanding it.

No need to be a new comer. I am not specially a good writer. And the 
matter is complex.

>>  I've taken a few notes while reading it, and I paste them below, 
>>The Internet upper layer began with three applications (Telnet, 
>>FTP, and RJE). Several applications have been added
>>

This is history.

>>"these" is slightly ambiguous in such a statement.

OK. Would "to consider a response to usage oriented needs". The 
important point is "a" to show that there could be other responses as 
well or better ones. Because the whole thing is on the usage side, 
not on the internet side.

>>prestag is defined by example as a generalization of that concept.)

Prestag is quoted as a new term in the introduction. I will expend 
the paragraph above to indicate that prestage is generalization of the prefix.

>>parameters could also be envisaged, making that extra data 
>>available for protocols built upon such layer, but TCP/IPP is a 
>>misnomer if such layer can transparently use, say, SCTP instead of 
>>TCP, or IPv6 instead of IPv4.

TCP/IPP is not defined in this document, only the probable need is 
alluded to. Changing a protocol is not changing the architecture as 
long as the change is transparent to those not using it. The most 
probable solution for TCP/IPP is very simple: to use a one bit in the 
header to signal the availbility of metadata (what actually means the 
Internet Plus is activated on the sending end. How to signal this is 
worth some consideration. You are correct that it should be noted as IPP.

>>label types: data labels and compression labels."

Thank you. I did not notice that Interstellar Switches Draft had made 
it to an RFC yet. Did you notice some contradictions in some other 
place? I need to reread the text now it is published.

>>readers wondering about what cases are allowed to break DNS rules.

Good.

>>cannot be used to _accentuate_ a label, in the sense of tweaking 
>>its semantics. A transparent behavior similar to IDNA, where the 
>>encoded name is nonsensical and hence never displayed, could be 
>>achieved with per-user settings, and that is, IMHO, the limit of 
>>the example. BTW, making the only example in Arabic --or Greek, for 
>>that matter-- may also limit understanding somewhat ;-)

I just wanted to say that architecturally Internet Plus strictly 
respect the IAB rule set-up for IDNA - not to interfere with DNS.

>>mangling only. (If that were true, the term "semantic" would be a misnomer.)

IRT what I underestand when you talk of i18n mangling:
1. any constraint on the net byte level neutrality affects the 
semantic bandwidth, since it may block some strings which carry a meaning?
2. would probably be addressed in saying ?
"any constraint related to any byte level limitations (for example: 
i18n characters mangling or IDNA relate filtering) and, therefore, 
the semantic bandwidth of the Internet wire".

>>Internet" and "the PLUS" as separate parts, because Internet PLUS 
>>is meant to eventually be part of the Internet, and hence, at some 

There is absolutely no intent to have the plugged layers being 
integrated into the Internet. What is described here is how they are 
plugged into the internet. This will be the same for any Internet 
interoperable technology from the past or in the future. "PLUS" is 
certainly a good buzword as it corresponds to what the Internet 
misses to support the Intersem. But it is on the intersem side in 
Vint's opinion.

>>allowed in ADNs, e.g. parentheses as in 
>>www.example(my-binding).org, or john(tel).example.net --along the 
>>line of [email-masked].

You are fully correct. This is something I forgot to rephrase. This 
was meant for a direct DN like use in different languages. Also, 
because in programing, structures are tld.level1.level2. I also 
forget to rewrite the example part to show that bcd---efg means a 
prefix and a suffix and not core domain name; what can be used to 
talk to a gateway or possibly call the root of a secondary space. I 
will use your example.

>>That's not strictly true if part of the UDN is going to be stored 
>>at an intermediate layer, e.g. the virtual host name (mentioned in 
>>a previous comment about TCP/IPP.)

Correct. I meant at the DN/IDN level. Will correct it.

I must confess that I focus right now on the semantic addressing 
related issues because I proposed to use the ".fra" space as a 
taxonomy for an open interknowledge ontology serving as a  a semantic 
referential system. But obviously UDN can be used in the way people 
want for whatever applications.

Thanks for your inputs/

Actually the first try was to document the semantic addressing system 
need, as an IETF customer. But it became very complex very soon. So, 
the best was to define what we need from the Internet and that the 
IAB can review. And to proceed more slowly on an practical 
experimentation basis for the Intersem, but there is a need of some 
development !

Best
jfc

---

From: Marie-France Berny <[email-masked]>
Date: Sun, 7 Jun 2009 13:48:02 +0200

Dear Jefsey,Let me comment this.

2009/6/7 JFC Morfin <[email-masked]>

>>> it.
> No need to be a new comer. I am not specially a good writer. And the matter
> is complex.

Everyone is a new comer. We just are users attempting something new !
Welcome among us !

>>> protocol header is probably needed for delivering the naming information
>>> when the used protocol does not do it
>>>
>>> architecture must not be affected. It should be possible to add names on a
>>> protocol by protocol basis (as in the Server Name Indication of rfc4366). A
>>> generic layer to store needed extra parameters could also be envisaged,
>>> making that extra data available for protocols built upon such layer, but
>>> TCP/IPP is a misnomer if such layer can transparently use, say, SCTP instead
>>> of TCP, or IPv6 instead of IPv4.
>>>
>>
> TCP/IPP is not defined in this document, only the probable need is alluded
> to. Changing a protocol is not changing the architecture as long as the
> change is transparent to those not using it. The most probable solution for
> TCP/IPP is very simple: to use a one bit in the header to signal the
> availbility of metadata (what actually means the Internet Plus is activated
> on the sending end. How to signal this is worth some consideration. You are
> correct that it should be noted as IPP.

Question: are we really interested in the Internet?
We started from the Intersem, found it was too complex for us to explain to
IETF people. Se we went to an Internet Pile and kept the Application layer
not to change anything and to have the DNS.

As you say ...

>
> I just wanted to say that architecturally Internet Plus strictly respect
> the IAB rule set-up for IDNA - not to interfere with DNS.
>
>  ---
>>> This chapter gives the impression that we are talking about i18n mangling
>>> only. (If that were true, the term "semantic" would be a misnomer.)
>>>
>>
>
> 1. any constraint on the net byte level neutrality affects the semantic
> bandwidth, since it may block some strings which carry a meaning?
> "any constraint related to any byte level limitations (for example: i18n
> characters mangling or IDNA relate filtering) and, therefore, the semantic
> bandwidth of the Internet wire".
>
>>> described is also going to generate confusion. Even if it is named "Internet
>>> PLUS", it doesn't make much sense to distinguish "the Internet" and "the
>>> PLUS" as separate parts, because Internet PLUS is meant to eventually be
>>> part of the Internet, and hence, at some point, it will be the Internet
>>> tout-court.
>>>
>>
> There is absolutely no intent to have the plugged layers being integrated
> into the Internet. What is described here is how they are plugged into the
> internet. This will be the same for any Internet interoperable technology
> from the past or in the future. "PLUS" is certainly a good buzword as it
> corresponds to what the Internet misses to support the Intersem. But it is
> on the intersem side in Vint's opinion.

I a not sure this would be good English, but we could use "Inter Pluggable
Layer User Systemic" or Systematic ?

>
>  ---
>>> This means that nothing, that it permits to dynamically do could, which
>>> in turn not be statically obtained by using "Host.txt".
>>>
>>> That's not strictly true if part of the UDN is going to be stored at an
>>> intermediate layer, e.g. the virtual host name (mentioned in a previous
>>> comment about TCP/IPP.)
>>>
>>
> I must confess that I focus right now on the semantic addressing related
> issues because I proposed to use the ".fra" space as a taxonomy for an open
> interknowledge ontology serving as a  a semantic referential system. But
> obviously UDN can be used in the way people want for whatever applications.

We are going to get confusion at generalising too much. We need to respect
UIR/IRIs.

Thanks for your inputs/
>
> Actually the first try was to document the semantic addressing system need,
> as an IETF customer. But it became very complex very soon. So, the best was
> to define what we need from the Internet and that the IAB can review. And to
> proceed more slowly on an practical experimentation basis for the Intersem,
> but there is a need of some development !

This is why I suggest we stick to our needs. If some people want more, up to
them to document it !

Marie-France

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 08 Jun 2009 12:19:43 +0200

JFC Morfin wrote:
> Prestag is quoted as a new term in the introduction. I will expend the 
> paragraph above to indicate that prestage is generalization of the prefix.

The prefix or the concept?

Obviously xn-- is much shorter than, say, application/octet-stream.
However, it is interesting to recall that Iana just selected a random
prefix rather than setting up a registry of reserved prefixes (compare
http://iana.org/cctld/ietf-announce-30jan03.txt and
http://iana.org/assignments/media-types/). Given that the basic 
problems were similar, conveying binaries through ascii, the 
difference between the respective approaches is characteristic of one 
shot hacks versus expandable architectures.

Generalizations can also stem from the enclosed space that rfc3490 has
added between UDNs and ADNs. Initially filled with punycode
processing, that space can be dilated at will. Its result is not
necessarily a prefixed label. To the opposite, requiring a reserved
prefix has stronger standardization constraints that limit the
generality of the concept.

I agree with Marie-France that generalizing too much may result in 
confusion; however, falling too short has even worse implications...

---

From: JFC Morfin <[email-masked]>
Date: Mon, 08 Jun 2009 18:47:50 +0200

>The prefix or the concept?

The prestag concept is a generalisation of the IDNA prefix concept, 
the way it can be read, i.e. the use of a part of a label to convey 
an information to a layer, that is accepted by the DNS.

>difference between the respective approaches is characteristic of 
>one shot hacks versus expandable architectures.

Actually, I proposed roughly the InterPlus to the WG-IDNA in 2002, 
calling the pseudonetwork layer application an "access engine" (from 
a large application prototype and the dot-root test bed of the DNS 
governance evolution). I also, underlined that the prefix was 
creating a left to right ("--" separated) hierachy local to each 
label, in addition to the right to left "." separated hierarchy.

The reason why I am shy in describing is that it seems to be the 
usual way of IETF documents. Also, because I want to establish that 
InterPlus brings nothing which as not been tested for a long (the 
"xn--" format is tested for 8 years as transparent to the DNS).

>added between UDNs and ADNs.

Yes. This is why the text takes punycode as an application/algorithm 
example. So, everyone understands that punycode can be respected. But 
that familly of application/algorithm can be indefinitly expanded (in 
addition of piles being concatenated) in dialoging with other 
appluications through the interapplication layer. Thought, the result 
must be a registered (I)DN to go through.

BTW, I do not want to expand too much in this document, but now it is 
not negatively commented by some people, I will add in the Network 
Application description that the DNS application can be local to the 
user if the network being used has not it. I did not want to do that 
before Unbound was not released under Windows. This is now the case, 
however, I have not had the time yet to load and test it.

>  Initially filled with punycode

If you read it well, the prestag can be a prefix or a suffix. And 
nothing prevents the core of the label to be empty (ab---cd), nor to 
read the entire label as a prestag (I think I give the example of the 
TLDs), nor to consider composed prestags.

>confusion; however, falling too short has even worse implications...

Worse, I do not know. But limiting innovative thinking yes. This is 
the purpose of discussing the text to also feel how far thing 
can/should be described in order not to hurt conservative spirits (so 
the position gets used) and not to block innovative ones (so it gets usefull).

I plan to review the text in coming days before sending it to IAB. I 
will consider all your remarks in so doing.
Thanks !
jfc

---

From: JFC Morfin <[email-masked]>
Date: Mon, 15 Jun 2009 20:34:05 +0200

I am sorry for being late in reviewing the Interplus document. I am
overloaded with family, business and political issues. I will try to go
ahead in the coming days.
jfc

2009/6/8 JFC Morfin <[email-masked]>

> The prestag concept is a generalisation of the IDNA prefix concept, the way
> it can be read, i.e. the use of a part of a label to convey an information
> to a layer, that is accepted by the DNS.
>
>> http://iana.org/assignments/media-types/). Given that the basic problems
>> were similar, conveying binaries through ascii, the difference between the
>> respective approaches is characteristic of one shot hacks versus expandable
>> architectures.
>>
>
> Actually, I proposed roughly the InterPlus to the WG-IDNA in 2002, calling
> the pseudonetwork layer application an "access engine" (from a large
> application prototype and the dot-root test bed of the DNS governance
> evolution). I also, underlined that the prefix was creating a left to right
> ("--" separated) hierachy local to each label, in addition to the right to
> left "." separated hierarchy.
>
> The reason why I am shy in describing is that it seems to be the usual way
> of IETF documents. Also, because I want to establish that InterPlus brings
> nothing which as not been tested for a long (the "xn--" format is tested for
> 8 years as transparent to the DNS).
>
> example. So, everyone understands that punycode can be respected. But that
> familly of application/algorithm can be indefinitly expanded (in addition of
> piles being concatenated) in dialoging with other appluications through the
> interapplication layer. Thought, the result must be a registered (I)DN to go
> through.
>
> BTW, I do not want to expand too much in this document, but now it is not
> negatively commented by some people, I will add in the Network Application
> description that the DNS application can be local to the user if the network
> being used has not it. I did not want to do that before Unbound was not
> released under Windows. This is now the case, however, I have not had the
> time yet to load and test it.
>
> If you read it well, the prestag can be a prefix or a suffix. And nothing
> prevents the core of the label to be empty (ab---cd), nor to read the entire
> label as a prestag (I think I give the example of the TLDs), nor to consider
> composed prestags.
>
> Worse, I do not know. But limiting innovative thinking yes. This is the
> purpose of discussing the text to also feel how far thing can/should be
> described in order not to hurt conservative spirits (so the position gets
> used) and not to block innovative ones (so it gets usefull).
>
> I plan to review the text in coming days before sending it to IAB. I will
> consider all your remarks in so doing.
> Thanks !
> jfc
>
>
>