Fixing display variations (was: AW: Eszett and IDNAv2 vs IDNA2008)

[JFC Morfin]

Andrew, John,Let me try to comment on this and give inputs.

2009/3/13 Andrew Sullivan <ajs at shinkuro.com>

> On Fri, Mar 13, 2009 at 07:14:00PM +0100, JFC Morfin wrote:
> > you cannot avoid the fact that multilingualization needs a
> > presentation layer the Internet technology presently has not.
>
> I can buy that.  What isn't clear to me is what part of the
> presentation layer the IETF needs to build.


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.

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

What I think it the case
> is that the IETF needs to provide the infrastructure by which
> presentation layers can be built, without providing the presentation
> layer itself.


I agree. However, there should be a common modeling approach in order to
support interoperability (digital) and interintelligibilty (semantic). RFC
4037 offers the solution.

This is because the IETF does not have the expertise,
> really, to do user interface things (and I think the presentation
> layer is somewhere up in that user interface space).


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.

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.

So, if someone were to put together a document outlining what any
> presentation layer needs in terms of information about network names,
> that would probably be interesting input.  It would not, however, be
> input for this WG working on the current problem it's aiming to solve,
> which is internationalization of the DNS and _not_ presentation
> problems of netnames.


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.

I documented and reported this as an example of a possible innovation
transition deployment strategy :
http://iucg.org/drafts/draft-iucg-innov-dep-strat-00.txt
we could test with the linguistic DN
support.<http://iucg.org/drafts/draft-iucg-innov-dep-strat-00.txt>


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

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.

A simplist diagram :

1. user applications deal with usage names (U-labels on a language/script
basis)
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
3. DNS is unafcted and answers normally
4. ML-DNS massages the response A-label into U-label or restore it via the
ID.

- the typography is respected
- the DNS is respected
- there is no change in the browser, protocols, etc.
- additional services can be added in parallel (such as security, parallel
DNS classes, Minor protection, etc.)

Just for information (just entered OPES DNS in Google)
http://osdir.com/ml/ietf.opes/2003-04/msg00218.html

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.

However, that kind of change is not that easy.

jfc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090314/658d97a9/attachment.htm