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

[JFC Morfin <[e-mail]>]

At 20:49 04/06/2009, JFC Morfin wrote:
>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:
>>JFC Morfin wrote:
>>>Eventually ... I compeleted it :-) !
>>>For your information the bilingual IUCG Draft on the Internet PLUS 
>>>is now on http://iucg.org/wiki/Internet_PLUS.
>>
>>(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.

>>>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.

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, 
>> 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.

This is history.

>>---
>>The proposition of this memo is to consider a response to these needs
>>
>>"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.

>>---
>>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.)

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.

>>---
>>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.

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.

>>---
>>RFC 2929 says: "At the present time, there are two categories of 
>>label types: data labels and compression labels."
>>
>>s/2929/5395/

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.

>>---
>>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.

Good.

>>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 ;-)

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

>>---
>>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.)


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".

>>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.

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.

>>---
>>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 user#[e-mail].

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.

>>---
>>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.)

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