RE: [idn] Requirements I-D (draft-ietf-idn-requirements-04.txt)

[James Seng <James@Seng.cc>]

forwarded

-------- Original Message --------
Subject: BOUNCE idn@ops.ietf.org:    Non-member submission from ["Larry
Masinter" <masinter@attlabs.att.com>]
Date: Sun, 01 Oct 2000 17:30:12 -0700
From: "Larry Masinter" <masinter@attlabs.att.com>
To: "Zita Wenzel" <zita@ISI.EDU>, <idn@ops.ietf.org>
Subject: RE: [idn] Requirements I-D (draft-ietf-idn-requirements-04.txt)
Date: Sun, 1 Oct 2000 17:28:09 -0700

In section 1.5, please include something like

> Frequently, hostname-to-address service is part of an overall
> system for interpretation of URLs.

since URL resolution (usually http URL resolution) is one of the
more common applications.

OLD: 
< These services exist, conceptually, at the Application/Resolver
> interface, NOT at the DNS-service interface. This document attempts to
< set requirements for an equivalent of the "used services" given above,
< where "hostname" is replaced by "Internationalized Domain Name". This
< doesn't preclude the fact that IDN should work with any kind of DNS
< queries.  IDN is a new service. Since existing protocols like SMTP or
< HTTP use the old service, it is a matter of great concern how the new
< and old services work together, and how other protocols can take
< advantage of the new service.

I think what you're trying to say is the following:

These services primarily are features of the interface between the
Application and Resolver, not at the "DNS service" interface above.
> This document attempts to set requirements for a overall system for
> using internationalized names instead of ASCII hostnames for all of
> the above services, as well as the noting the implications for necessary
> support in the DNS service interface, system infrastructure, and
> user interfaces. This overall system is called IDN (Internationalied
> Domain Names) in this document. Since existing applications use
> the existing infrastructure, interoperability of existing DNS
> with IDN, and support for forward migration, is of great concern.

Where you say

# and "protocol" whenever a requirement
# is believed to constrain the possible implementation.

This is very confusing. The word "protocol" is used in the IETF to talk
about network protocols, and not to talk about implementations. I
think that the word "IDN system" could be used in most places.


< MUST NOT damage present DNS protocol interoperability. It MUST make the

> MUST NOT damage present DNS interoperability. It MUST make the

(DNS interoperability is a protocol and implementation issue)

< [4] The protocol SHOULD allow creation of caching servers that do

> [4] The IDN system SHOULD allow creation ....

(this is a requirement on the overall system)

>....

(more later)