Subject: [idn] Re: Re: [idn] San Diego Meeting Notes

From: [email-masked]
Date: Thu, 25 Jan 2001 20:32:11 +0900

I don't think it's a right approach focusing on a short term solution without
clear understaning/evaluation on what a long term solution would be. Moreover, the proposed decision should be made after thorough analysis of possible problems when non-ACE is used (e.g. UTF-8) which I suggested at the San Diego meeting.

Dongman Lee

> 
> 
> -----원본메시지-----
> 보낸사람: "James Seng/Personal" 
> 받는사람: [email-masked]
> 날짜: 2001/01/24(수)06:38
> 제목: Re: [idn] San Diego Meeting Notes
> 
> Dear all,
> 
> I would like to re-emphasis a few 'consensus' in the meeting in San
> Diego.
> 
> a) Requirements I-D to move to Last Call after last minor edition.
> 
> b) Strawpoll agrees with Protocol Design Team recommendation to focus
>    on "ACE on Application" now but do not rejecting a longer term
>    solution in future.
> 
> c) Strawpoll agrees that the Nameprep Design Team is working in the
>    right direction. (See Nameprep-02)
> 
> If you have any objection (I know a few of you do), please raise them
> now.
> 
> If there is no major objection, then the next step would include
> 
> 1. Zita will do the Requirements -04 and we will move to Last Call.
> 
> 2. Protocol Design Team (or someone) should start working on writing
>    an I-D for the IDN Protocol. As it stands now, IDNA seem the closest
>    we have.
> 
> 3. An ACE Design Team may be form to investigate what is the correct
>    ACE to use for (2).
> 
> In additional, I would also like to propose to update the Goals and
> Milestone section of the WG Charter to reflect our progress more
> accurately.
> 
> Your comments would be appreciated.
> 
> -James Seng
> 
> 
> 
> 
> 
> 
>

---

From: "Edmon" <[email-masked]>
Date: Thu, 25 Jan 2001 10:23:37 -0500

I really agree with Dongman Lee that we should understand the long term solution before rushing into an intermediate fix/hack.

About what happens to 8bit requests as they get sent, I have been urging that we should do some kind of study, at least to let everyone know what will happen if these DNS packets are forced through from, say a common application such as the browser, through the OS kernel.  Cause even if we use ACE, these requests will be sent via non-compliant browsers to affect the system.

To that end, I have finally put together a bunch of hand notes that we have been collecting about the "known issues" for multilingual domain names.  Please take a look and comment on it and add to it too.  http://www.openidn.org/issues.html

Dongman, do you have any studies on the effects of 8bit requests sent via other applications or OS?

Edmon

----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] 
  Sent: Thursday, January 25, 2001 6:32 AM
  Subject: [idn] Re: Re: [idn] San Diego Meeting Notes

  Dongman Lee

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 25 Jan 2001 08:52:46 -0800

At 8:32 PM +0900 1/25/01, [email-masked] wrote:
>clear understaning/evaluation on what a long term solution would be.

Could you clarify your reason for this? As long as the short term 
presentation-layer solution doesn't force any design change for the 
long-term solution, it seems that the two can be unrelated. Further, 
having a short-term solution in place gives people more time to 
figure out what the long term solution should be, and will also give 
some valuable data about the attributes of the names that need to be 
handled in the long term solution.

>  Moreover, the proposed decision should be made after thorough 
>analysis of possible problems when non-ACE is used (e.g. UTF-8) 
>which I suggested at the San Diego meeting.

To be specific, the proposals are all for non-marked UTF-8, and many 
of the proposals are for non-marked UTF-8 without nameprep. That 
analysis has already appeared on this mailing list. Today's 
applications allow you to enter DNS names in many encodings, not just 
UTF-8. People from companies that take advantage of this sad fact are 
quite active in this WG. For non-marked UTF-8 (with or without 
nameprep), non-uniqueness of names due to different names in 
different encodings having the same octet sequences raises so many 
security issues that it seems silly to even consider it.

Any proposal for marked UTF-8 with nameprep immediately takes on all 
of the presentation issues that IDNA has, and further forces many 
changes to other IETF protocols and to many non-protocol services 
that currently do DNS name validation. The purpose of using an ACE 
encoding instead of a marked UTF-8 encoding is to allow IDN to be 
used more quickly by more users. It seems unlikely that this group 
would choose a marked encoding that forces more changes in protocols 
and applications before it can be reliably deployed.

Does it seem useful for this group do more analysis even in the face 
of those issues? Put another way, the IETF generally does not create 
proposals with known massive security holes in them. Is it OK for IDN 
to be designed with known security problems?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Jan 2001 14:35:33 -0500

> I really agree with Dongman Lee that we should understand the long term
> solution before rushing into an intermediate fix/hack.

Any notion of "the" long term solution is pure fantasy.  There are lots
of protocols using DNS names as protocol elements.  Each one has different 
issues associated with using UTF-8 (or some other non-ASCII representation) 
in the context of that protocol.  Each one has different degrees of 
deployment and different difficulties associated with transition to a new
protocol version and with upgrading existing implementations.
Some protocols will necessarily get upgraded before others; some may
never be upgraded at all, or may become obsolete (perhaps replaced by 
something completely different) before they are upgraded.

Keith

---

From: "Edmon" <[email-masked]>
Date: Thu, 25 Jan 2001 16:56:45 -0500

I appreciate that there are different issues associated with UTF-8 or other
non-ASCII approach, my main point is that even if we do go to IDNA, chances
are that users unknowingly will still be sending multilingual dns requests
through existing products that are non-IDNA aware.  The known issues paper
is used to document these instances that cannot be avoided.
I truly believe that we should prepare ourselves for these situations.  It
would be greatly appreciated if anyone that really care about getting
multilingual domain names usable on the Internet to give me some comments on
the paper at http://www.openidn.org/issues.html so that more people will
know about these behaviours as multilingual names are deployed.

I would make it into an Internet draft if anyone thinks that it is something
valuable.
Edmon

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Jan 2001 17:30:15 -0500

> through existing products that are non-IDNA aware.  

agreed.  I think such a document could be useful, with the following caveats:

- it would be very hard to make it sufficiently comprehensive that 
  it could serve as guidance for the design of an IDN solution, or
  even to serve as a guide for users wanting to know which products
  to buy.

- it could take a large amount of time and energy

so I wouldn't mind at all seeing such a document produced, but I wouldn't 
want to see such an effort divert resources from the primary work on IDNs, 
or delay the primary work on IDNs.

regarding the document you referenced (http://www.openidn.org/issues.html)

- there are many more kinds of components affected than those that you
  list (web browser, kernel, proxy server)

- there are many more implementations of each of these kinds of components
  than those that you list.  

- there are other platforms than those you list, with different issues
  than these.

all of which just illustrates that it's difficult to make this kind of
list comprehensive.

- it's not clear exactly what is meant by "kernel" or how it comes into
  play in the interaction between applications.

- it appears to be difficult to isolate or even document the nature of 
  certain problems, especially given that the behavior may change 
  depending on program preferences, presense of proxies, choice of 
  platform, etc.

- the issues you cite are good examples of how 8-bit characters get mangled 
  by some existing programs, but it's hard to know how to use this 
  information except to demonstrate that 8-bit characters get mangled
  in a variety of ways. 

- the "solution" it recommends for squid is somewhat dubious:
  it oversimplifies the problem of making IDNs work for the web.

  e.g. even if we adopted a UTF-8 on-the-wire solution for URLs in the 
  HTTP protocol (something that is not within the scope of this group
  to decide), it's not sufficient to simply change these programs to be 
  8-bit transparent for typed-in URLs.  there are other interfaces 
  which contain URLs (web pages, config files, APIs used to control  
  the browser, cut-and-paste), nameprep would certainly have to be 
  applied to URLs in the browser so that local caching would work 
  (even if proxies and remote servers were also taught to do nameprep)

---

From: "Edmon" <[email-masked]>
Date: Fri, 26 Jan 2001 10:02:18 -0500

Thanks so much for your comment.  I understand that it would be very hard to
make it totally comprehensive, but at least it goes to show that even when
OSs go UTF, it does not necessarily mean that DNS packets are correctly
packaged in UTF.  Which means that regardless of whether we choose
UTF8/16/32 or even ACE most applications still have to be changed.  However
I do agree that, making UTF8/16/32 right should be easier than introduce yet
another transformation.

As we go along, we will continue to update the document on other
applications.  Meanwhile, I look to all of you all to add to the document if
you already know of some irregularities regarding certain applications.
Once its considerably comprehensive, I think it is valuable to be turned
into a draft.

Edmon

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Jan 2001 10:29:12 -0500

--On Thursday, 25 January, 2001 08:52 -0800 "Paul Hoffman / IMC"
<[email-masked]> wrote:

> Could you clarify your reason for this? As long as the short
> term presentation-layer solution doesn't force any design
> change for the long-term solution, it seems that the two can be
> unrelated. Further, having a short-term solution in place gives
> people more time to figure out what the long term solution
> should be, and will also give some valuable data about the
> attributes of the names that need to be handled in the long
> term solution.

Paul, I would just remind you that, for Internet applications,
once something is deployed that does the relevant job at least
half-adequately (or even a bit less), and no matter how "short
term" it is intended to be, our success level in replacing it
with good (and "long term") solutions has been just about zero.
Indeed, the only exceptions I can think of involve incremental
improvements to the same protocol, not replacement by something
new.

     john

---

From: GIM Gyeongseog-KIM Kyongsok <[email-masked]>
Date: Sat, 27 Jan 2001 16:46:42 +0900 (KST)

> with good (and "long term") solutions has been just about zero.

i have nearly the same concern.

>      john

김 경석, 부산대 정보 컴퓨터 공학부; 
  KIM Kyongsok/GIM Gyeongseog, Busan National Univ.
  [email-masked], http://HANGEUL.cs.pusan.ac.kr/hangeul/
  Ph: (051) 510-2292, Fax: (051) 515-2208