Andrew, John,<div>Let me try to comment on this and give inputs.<br><br><div class="gmail_quote">2009/3/13 Andrew Sullivan <span dir="ltr"><<a href="mailto:ajs@shinkuro.com">ajs@shinkuro.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Mar 13, 2009 at 07:14:00PM +0100, JFC Morfin wrote:<br>
> you cannot avoid the fact that multilingualization needs a<br>
> presentation layer the Internet technology presently has not.<br>
<br>
</div>I can buy that. What isn't clear to me is what part of the<br>
presentation layer the IETF needs to build. </blockquote><div><br></div><div>This is something I will not dare to advise on a general basis. The need I perceive is for the DNS as an application, and languages as a needed presentation. The second need I perceive is for the user and user's applications to interact with/command the presentation layer. I can only suggest the IETF solution we worked on, but no one deployed so far.</div>
<div><br></div><div>It would also be helped by what I name apervasive "netix", i.e. an internet interapplications system over the application layer and below usage layers (user application, agent, user, relational spaces, referentials).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">What I think it the case<br>
is that the IETF needs to provide the infrastructure by which<br>
presentation layers can be built, without providing the presentation<br>
layer itself. </blockquote><div><br></div><div>I agree. However, there should be a common modeling approach in order to support interoperability (digital) and interintelligibilty (semantic). RFC 4037 offers the solution.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">This is because the IETF does not have the expertise,<br>
really, to do user interface things (and I think the presentation<br>
layer is somewhere up in that user interface space).</blockquote><div><br></div><div>Presentation is layer 6, i.e. servicing network applications (DNS, Mail, etc.) within the end to end segment, not user applications which are outside of the network design and intermanagement influence.</div>
<div><br></div><div>The job of a presentation layer is within the network to securly and surely present A-labels when U-labels are sent to the DNS.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
So, if someone were to put together a document outlining what any<br>
presentation layer needs in terms of information about network names,<br>
that would probably be interesting input. It would not, however, be<br>
input for this WG working on the current problem it's aiming to solve,<br>
which is internationalization of the DNS and _not_ presentation<br>
problems of netnames.</blockquote><div><br></div><div>Agreed. This is why I suggest that this WG presents IDNA as a stable internationalization solution. Then, that _another_ WG integrates that internationalization solution as the English ASCII default part of a global multilingualization architecture. </div>
<div><br></div><div>I documented and reported this as an example of a possible innovation transition deployment strategy : <a href="http://iucg.org/drafts/draft-iucg-innov-dep-strat-00.txt">http://iucg.org/drafts/draft-iucg-innov-dep-strat-00.txt we could test with the linguistic DN support.</a></div>
<div><br></div><div><br></div><div>Actually, there is an presentation (and possibly other virtual) layer architecture, supported by RFC 4037 OCP shims (OPES). There is therefore an HTTP "presentation layer" which is documented by standard track RFC 4236. The problem was that I was unable to make people in the WG/OPES fully understand of the overlay system as network layers (I call ONES - open network extended system). </div>
<div><br></div><div>There are tremendous possibilities there, paralleling (and therefore respecting) the Internet end to end network with extended network services (session ? and definitly presentation). But they cannot be documented and deployed without long testing. This is why I am impatient to see IDNA to be produced, ICANN not to confuse everything with their money oriented culture, and ML-DNS experimentation to be made possible.</div>
<div><br></div><div>A simplist diagram :</div><div><br></div><div>1. user applications deal with usage names (U-labels on a language/script basis)</div><div>2. they are sent to the DNS, intercepted by the ML-DNS presentation layer (for example at ISP access point in linguistic countries) which transform the U-labels in A-labels in the request it passes to the DNS</div>
<div>3. DNS is unafcted and answers normally</div><div>4. ML-DNS massages the response A-label into U-label or restore it via the ID. </div><div><br></div><div>- the typography is respected</div><div>- the DNS is respected</div>
<div>- there is no change in the browser, protocols, etc.</div><div>- additional services can be added in parallel (such as security, parallel DNS classes, Minor protection, etc.)</div><div><br></div><div>Just for information (just entered OPES DNS in Google)</div>
<div><a href="http://osdir.com/ml/ietf.opes/2003-04/msg00218.html">http://osdir.com/ml/ietf.opes/2003-04/msg00218.html</a><br></div><div><br></div><div>My opinion as discussed with Jim Bound over the ROAP issue, is that the technology is quite robust and powerful but was designed with an unilateral paradigm in mind. It can most probably support much more if it is just approached with a multilateral paradigm. </div>
<div><br></div><div>However, that kind of change is not that easy. </div><div><br></div><div>jfc</div><div><br></div></div></div>