draft-ietf-idn-compare-00.txt   draft-ietf-idn-compare-01.txt 
Internet Draft Paul Hoffman Internet Draft Paul Hoffman
draft-ietf-idn-compare-00.txt IMC & VPNC draft-ietf-idn-compare-01.txt IMC & VPNC
June 14, 2000 July 11, 2000
Expires in six months Expires in six months
Comparison of Internationalized Domain Name Proposals Comparison of Internationalized Domain Name Proposals
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
skipping to change at line 92 skipping to change at line 92
proposed alternatives, not just the ones that fully match the proposed alternatives, not just the ones that fully match the
requirements in [IDN-REQ]. It will serve as a summary of the discussion requirements in [IDN-REQ]. It will serve as a summary of the discussion
in the IDN WG for readers in the future who may want to know why certain in the IDN WG for readers in the future who may want to know why certain
alternatives were not chosen for the eventual protocol. alternatives were not chosen for the eventual protocol.
The proposal drafts covered in this document are: The proposal drafts covered in this document are:
[DUERST] Character Normalization in IETF Protocols, [DUERST] Character Normalization in IETF Protocols,
draft-duerst-i18n-norm-03 draft-duerst-i18n-norm-03
[HOFFMAN] Compatible Internationalized Domain Names Using Compression, [IDNE] Internationalized domain names using EDNS (IDNE),
draft-hoffman-idn-cidnuc-03 draft-ietf-idn-idne-01
[KWAN] Using the UTF-8 Character Set in the Domain Name System, [KWAN] Using the UTF-8 Character Set in the Domain Name System,
draft-skwan-utf8-dns-03 draft-skwan-utf8-dns-03
[OSCARSSON] Internationalisation of the Domain Name Service, [RACE] RACE: Row-based ASCII Compatible Encoding for IDN,
draft-oscarsson-i18ndns-00 draft-ietf-idn-race-00
[SENG] UTF-5, a transformation format of Unicode and ISO 10646, [SENG] UTF-5, a transformation format of Unicode and ISO 10646,
draft-jseng-utf5-01 draft-jseng-utf5-01
1.2 Editor's note for the -00 draft [UDNS] Using the Universal Character Set in the Domain Name System
(UDNS), draft-ietf-idn-udns-00
This first draft is probably incomplete in many aspects. There may be
proposals that appeared on the mailing list or in conversation that I
did not include here, and there are likely to be pro and con arguments
that I have left out. Any such omission is not an indication of the lack
of merit, but instead an error on the editor's part. Also, if there are
proposals here that do not fulfill some of the requirements from
[IDN-REQ] but that fact is not reflected here, that is an omission that
should be corrected. In any case, please actively send comments and
corrections to this document to the IDN working group.
2. Architecture 2. Architecture
One of the biggest questions raised early in the IDN discussion was what One of the biggest questions raised early in the IDN discussion was what
the format of internationalized name parts would be on the wire, that the format of internationalized name parts would be on the wire, that
is, between the user's computer and the DNS resolvers. It was agreed is, between the user's computer and the DNS resolvers. It was agreed
that the DNS protocols certainly allow non-ASCII octets in domain name that the DNS protocols certainly allow non-ASCII octets in domain name
parts and resource records, but there was also acknowledgement that many parts and resource records, but there was also acknowledgement that many
protocols that rely on the DNS could not handle non-ASCII names due to protocols that rely on the DNS could not handle non-ASCII names due to
the design of the protocol. Section 3.1 of this document describes the the design of the protocol. Section 3.1 of this document describes the
skipping to change at line 146 skipping to change at line 137
in RFC 1034. in RFC 1034.
Pro: Easiest to describe. Only changes host name syntax, not any of the Pro: Easiest to describe. Only changes host name syntax, not any of the
related DNS protocols. related DNS protocols.
Con: Doesn't work with many exiting protocols that relies on DNS. Con: Doesn't work with many exiting protocols that relies on DNS.
Violates requirement [#9-02]. Violates requirement [#9-02].
2.2 arch-2: Send binary or ACE 2.2 arch-2: Send binary or ACE
[OSCARSSON] proposes using both binary and ACE formats on the wire. [UDNS] (and, later, [IDNE]) proposes using both binary and ACE formats
on the wire.
Pro: Allows protocols that can handle binary name parts to use them Pro: Allows protocols that can handle binary name parts to use them
directly, while allowing protocols that cannot use binary name parts to directly, while allowing protocols that cannot use binary name parts to
also handle names without conversion. Allows domain names in free text also handle names without conversion. Allows domain names in free text
to be displayed in binary even in systems that require ACE-formatted to be displayed in binary even in systems that require ACE-formatted
names on the wire. names on the wire.
Con: Requires all software that uses domain names to handle both Con: Requires all software that uses domain names to handle both
formats. Requires processing time for conversion of ACE formats into the formats. Requires processing time for conversion of ACE formats into the
format must likely used internally to the software. format must likely used internally to the software.
2.3 arch-3: Just send ACE 2.3 arch-3: Just send ACE
[HOFFMAN] and [SENG] propose that host naming rules remain the same and [RACE] and [SENG] propose that host naming rules remain the same and
that all internationalize domain names be sent in ACE format. that all internationalize domain names be sent in ACE format.
Pro: No changes at all to current DNS protocols. Pro: No changes at all to current DNS protocols.
Con: Requires all software to recognize ACE domain names and convert Con: Requires all software to recognize ACE domain names and convert
them to human-readable for display. This is true not only in domain them to human-readable for display. This is true not only in domain
names used on the wire but also domain names used in free text. names used on the wire but also domain names used in free text.
3. Names in binary 3. Names in binary
skipping to change at line 234 skipping to change at line 226
Con: Likely to cause disruption in software that is not binary-aware. Con: Likely to cause disruption in software that is not binary-aware.
Likely to cause systems to misread names and possibly (and incorrectly) Likely to cause systems to misread names and possibly (and incorrectly)
convert them to ASCII names by stripping off the high bit in octets; convert them to ASCII names by stripping off the high bit in octets;
this in turn would lead to security problems due to mistaken identities. this in turn would lead to security problems due to mistaken identities.
Returning binary host names to DNS queries is known to break some Returning binary host names to DNS queries is known to break some
current software. current software.
3.2.2 bin-2.2: Mark binary with IN bit 3.2.2 bin-2.2: Mark binary with IN bit
[OSCARSSON] describes using a bit from the header of DNS queries to mark [UDNS] describes using a bit from the header of DNS queries to mark the
the query as possibly containing a binary name part and indicating that query as possibly containing a binary name part and indicating that the
the response to the query can contain binary name parts. response to the query can contain binary name parts.
Pro: This bit is currently unused and must be set to zero, so current Pro: This bit is currently unused and must be set to zero, so current
software won't use it accidentally. No changes to any other part of the software won't use it accidentally. No changes to any other part of the
query or RRs. query or RRs.
Con: It's the last unused bit in the header and DNS folks have indicated Con: It's the last unused bit in the header and DNS folks have indicated
that they are very hesitant to give it up. that they are very hesitant to give it up.
3.2.3 bin-2.3: Mark binary with new QTYPEs 3.2.3 bin-2.3: Mark binary with new QTYPEs
Off-list discussion has mentioned using new QTYPEs to mark the query as [UDNS] using new QTYPEs to mark the query as possibly containing a
possibly containing a binary name part and indicating that the response binary name part and indicating that the response to the query can
to the query can contain binary name parts. QTYPEs are two octets long, contain binary name parts. QTYPEs are two octets long, and no QTYPEs to
and no QTYPEs to date use more than the lower eight bits, so one of the date use more than the lower eight bits, so one of the bits from the
bits from the upper octet could be used to indicate binary names. upper octet could be used to indicate binary names.
Pro: These bits are currently unused and must be set to zero, so current Pro: These bits are currently unused and must be set to zero, so current
software won't use them accidentally. No changes to any other part of software won't use them accidentally. No changes to any other part of
the query or RRs. Uses a bit that isn't as prized as the IN bit. the query or RRs. Uses a bit that isn't as prized as the IN bit.
Con: Software must pay more attention to the QTYPEs than it might have Con: Software must pay more attention to the QTYPEs than it might have
previously. previously.
3.2.4 bin-2.4: Mark binary with EDNS0 3.2.4 bin-2.4: Mark binary with EDNS
Off-list discussion has mentioned using EDNS0 [RFC2671] to mark the [IDNE] uses EDNS [RFC2671] to mark the query and response as containing
query as possibly containing a binary name part and indicating that the a binary name part.
response to the query can contain binary name parts.
Pro: There is little use of EDNS0 at this point, so it is very unlikely Pro: There is little use of EDNS at this point, so it is very unlikely
to have bad interactions with old software. to have bad interactions with old software. EDNS allows longer name
parts, and allows additional information (such as IDN version number)
in each name part.
Con: There is little use of EDNS0 and this might make implementation Con: There is little use of EDNS and this might make implementation
harder. harder.
4. Names in ASCII-compatible encoding (ACE) 4. Names in ASCII-compatible encoding (ACE)
Both arch-2 and arch-3 include domain name parts that are represented on Both arch-2 and arch-3 include domain name parts that are represented on
the wire in an ASCII-compatible encoding (ACE). This section describes the wire in an ASCII-compatible encoding (ACE). This section describes
some of the features of such names. some of the features of such names.
4.1 ace-1: Format 4.1 ace-1: Format
skipping to change at line 302 skipping to change at line 295
characters using a system similar to UTF-8. Characters from Basic Latin characters using a system similar to UTF-8. Characters from Basic Latin
and Latin-1 Supplement take 2 octets; Latin Extended-A through Tibetan and Latin-1 Supplement take 2 octets; Latin Extended-A through Tibetan
take 3 octets; Myanmar through the end of BMP take 4 octets; non-BMP take 3 octets; Myanmar through the end of BMP take 4 octets; non-BMP
characters take 5 octets. This means that names using all characters characters take 5 octets. This means that names using all characters
in the Myanmar through the end of BMP are limited to 15 characters. in the Myanmar through the end of BMP are limited to 15 characters.
Pro: Extremely simple. Pro: Extremely simple.
Con: Poor compression, particularly for Asian scripts. Con: Poor compression, particularly for Asian scripts.
4.1.2 ace-1.2: CIDNUC 4.1.2 ace-1.2: RACE
[HOFFMAN] describes CIDNUC, which is a two-step algorithm that first [RACE] describes RACE, which is a two-step algorithm that first
compresses the name part, then converts the compressed string into and compresses the name part, then converts the compressed string into and
ACE. Name parts in all scripts other than Han, Yi, Hangul syllables, and ACE. Name parts in all scripts other than Han, Yi, Hangul syllables,
non-BMP take up ceil(1.6*(n+1)) octets; name parts in those scripts and Ethiopic, and non-BMP take up ceil(1.6*(n+1)) octets; name parts in
any name that mixes characters from different rows in ISO 10646 take up those scripts and any name that mixes characters from different rows in
ceil(3.2*(n+1)) octets. This means that names using Han, Yi, or Hangul ISO 10646 take up ceil(3.2*(n+1)) octets. This means that names using
syllables are limited to 18 characters. Han, Yi, Hangul syllables, or Ethiopic, are limited to 18 characters.
(Note: this document used to be called CIDNUC.)
Pro: Best compression for most scripts, and similar compression for the Pro: Best compression for most scripts, and similar compression for the
scripts where it is not the best. scripts where it is not the best.
Con: More complicated than UTF-5. Not well optimized for names that have Con: More complicated than UTF-5. Not well optimized for names that have
mixed scripts, such as non-Latin names that use hyphen or ASCII digits. mixed scripts, such as non-Latin names that use hyphen or ASCII digits.
4.1.3 ace-1.3: Hex of UTF-8 4.1.3 ace-1.3: Hex of UTF-8
[OSCARSSON] describes "hex of UTF-8", which is a straight-forward An early draft described "hex of UTF-8", which is a straight-forward
hexadecimal encoding of UTF-8. Characters in Basic Latin (other than hexadecimal encoding of UTF-8. Characters in Basic Latin (other than
non-US-ASCII and hyphen) take 3 octets; Latin Extended-A through Tibetan non-US-ASCII and hyphen) take 3 octets; Latin Extended-A through Tibetan
take 5 octets; Myanmar through end of BMP take 7 octets; non-BMP take 5 octets; Myanmar through end of BMP take 7 octets; non-BMP
characters take 9 octets. This means that names using all characters characters take 9 octets. This means that names using all characters
in the Myanmar through the end of BMP are limited to 9 characters. in the Myanmar through the end of BMP are limited to 9 characters.
Pros: Very simple to describe. Pros: Very simple to describe.
Cons: Very poor compression for all scripts. Cons: Very poor compression for all scripts.
skipping to change at line 355 skipping to change at line 349
parts are ACE and which are non-ACE ASCII parts (such as current names). parts are ACE and which are non-ACE ASCII parts (such as current names).
This would only apply to an IDN proposal that used arch-2, not arch-3. This would only apply to an IDN proposal that used arch-2, not arch-3.
4.2.1 ace-2.1: Currently legal names 4.2.1 ace-2.1: Currently legal names
Name parts that are currently legal in RFC 1034 can be tagged to Name parts that are currently legal in RFC 1034 can be tagged to
indicate the part is encoded with ACE. indicate the part is encoded with ACE.
4.2.1.1 ace-2.1.1: Add hopefully-unique legal tag 4.2.1.1 ace-2.1.1: Add hopefully-unique legal tag
[HOFFMAN] proposes adding a hopefully-unique legal tag to the beginning [RACE] proposes adding a hopefully-unique legal tag to the beginning
of the name. The proposal would also work with such a tag at the end of of the name. The proposal would also work with such a tag at the end of
the name part, but it is easier for most people to recognize at the the name part, but it is easier for most people to recognize at the
beginning of name parts. beginning of name parts.
Pros: Easy for software (and humans) to recognize. Pros: Easy for software (and humans) to recognize.
Cons: There is no way to prevent people from beginning non-ACE names Cons: There is no way to prevent people from beginning non-ACE names
with the tag. Unless the tag is very unlikely to appear in any name in with the tag. Unless the tag is very unlikely to appear in any name in
any human language, non-ACE names that begin with the tag will display any human language, non-ACE names that begin with the tag will display
oddly or be rejected by some systems. oddly or be rejected by some systems.
skipping to change at line 380 skipping to change at line 374
mechanism where the checksum would be added to the beginning (or end) of mechanism where the checksum would be added to the beginning (or end) of
ACE name parts. ACE name parts.
4.2.2 ace-2.2: Currently illegal names 4.2.2 ace-2.2: Currently illegal names
Instead of creating names that are currently legal, another proposal is Instead of creating names that are currently legal, another proposal is
to create names that use the current ASCII characters but are illegal. to create names that use the current ASCII characters but are illegal.
4.2.2.1 ace-2.2.1: Add trailing hyphen 4.2.2.1 ace-2.2.1: Add trailing hyphen
[OSCARSSON] describes using a trailing hyphen as a signifier of an ACE An earlier draft described using a trailing hyphen as a signifier of an
name. ACE name.
Pros: It is surmised that most current software does not reject names Pros: It is surmised that most current software does not reject names
that are illegal in this fashion. Thus, there would be little disruption that are illegal in this fashion. Thus, there would be little disruption
to current systems. This mechanism takes up fewer characters than any to current systems. This mechanism takes up fewer characters than any
proposed in ace-2.1. proposed in ace-2.1.
Cons: Some current software is will probably break with this mechanism. Cons: Some current software is will probably break with this mechanism.
It goes against some current protocols that match the rules in RFC 1034. It goes against some current protocols that match the rules in RFC 1034.
5. Prohibited characters 5. Prohibited characters
skipping to change at line 452 skipping to change at line 446
6.1 canon-1: Type of canonicalization 6.1 canon-1: Type of canonicalization
The Unicode Consortium's recommendations and definitions of The Unicode Consortium's recommendations and definitions of
canonicalization [UTR-15] describes many forms of canonicalization that canonicalization [UTR-15] describes many forms of canonicalization that
can be performed on character strings. [DUERST] covers much of the same can be performed on character strings. [DUERST] covers much of the same
ground but makes more focused requirements for canonicalization on the ground but makes more focused requirements for canonicalization on the
Internet. Internet.
6.1.1 canon-1.1: Normalization Form C 6.1.1 canon-1.1: Normalization Form C
Both [UTR-15] and [DUERST] recommend Normalization Form C, as described [DUERST] recommends Normalization Form C, as described in [UTR-15], for
in [UTR-15]. This form is a canonical decomposition, followed by use on the Internet. This form is a canonical decomposition, followed by
canonical composition. canonical composition.
6.1.2 canon-1.2: Normalization Form KC 6.1.2 canon-1.2: Normalization Form KC
Discussion on the mailing list recommended Normalization Form KC, This Discussion on the mailing list recommended Normalization Form KC. This
form is a compatibility decomposition, followed by canonical form is a compatibility decomposition, followed by canonical
composition. Compatibility decomposition makes characters that have composition. Compatibility decomposition makes characters that have
compatibility equivalence the same after decomposing. compatibility equivalence the same after decomposing.
6.2 canon-2: Other canonicalization 6.2 canon-2: Other canonicalization
Host names may have special canonicalization needs that can be added to Host names may have special canonicalization needs that can be added to
those given in canon-1. those given in canon-1.
6.2.1 canon-2.1: Case folding in ASCII 6.2.1 canon-2.1: Case folding in ASCII
skipping to change at line 492 skipping to change at line 486
6.2.3 canon-2.3: Han folding 6.2.3 canon-2.3: Han folding
Discussion on the mailing list has raised the issue of equivalences in Discussion on the mailing list has raised the issue of equivalences in
some languages use of Han characters. For example, in Chinese, there are some languages use of Han characters. For example, in Chinese, there are
many traditional characters that have equivalent simplified characters. many traditional characters that have equivalent simplified characters.
Similarly, there are some Han ideographs for which there are multiple Similarly, there are some Han ideographs for which there are multiple
representations in ISO 10646. There are no well-established rules for representations in ISO 10646. There are no well-established rules for
such folding, and some of the proposed folding would be locale-specific. such folding, and some of the proposed folding would be locale-specific.
6.3 canon-3: Location of canonicalization
Canonicalization can be performed in any system in the DNS. Because it
is not a trivial operation and can require large tables, the location of
where canonicalization is performed is important.
6.3.1 canon-3.1: Canonicalize only in the application
Early canonicalization is a cleaner architecture design. Spending the
cycles on the end systems puts less burden on resolvers or servers in
the DNS service. When IDN is first adopted, the applications need to be
updated anyway to handle the new format for the names. It is easier for
people to upgrade their applications than their resolvers if they need a
new IDN feature.
6.3.2 canon-3.2: Canonicalize only in the resolver
Updating a single resolver provides new service to large number of
applications and (possibly) users. It is easier to find canonicalization
bugs in resolvers than in applications because the resolver has
predictable programmatic interfaces. IDN will probably be revised often
as new characters are added to ISO 10646, so updating smaller number of
resolvers is better than revising more applications. When an end user
has a problem with resolving an IDN name, it is much easier to test if
the problem is in the resolver than in the user's application.
6.3.3 canon-3.3: Canonicalize in the DNS service
Canonicalization should happen as late as possible so that changes in
the canonicalization algorithm don't orphan all applications and
resolvers. Some canonicalization discards information and so should be
delayed as long as possible. Canonicalization is practically free,
computationally (although it involves some large tables). Because adding
IDN to the DNS will happen over time, canonicalizing at the server will
minimize the number of things that need to be changed, and simplify and
centralize the process of change.
7. Transitions 7. Transitions
Early in the working group discussion, there was active debate about how Early in the working group discussion, there was active debate about how
the transition from the current host name rules to IDN would be handled. the transition from the current host name rules to IDN would be handled.
Given requirement [#1-02], this transition is quite important to Given requirement [#1-02], this transition is quite important to
deciding which proposals might be feasible. deciding which proposals might be feasible.
7.1 trans-1: Always do current plus new architecture 7.1 trans-1: Always do current plus new architecture
In this proposal, IDN will be used at the same time as the current DNS In this proposal, IDN will be used at the same time as the current DNS
forever. That is, IDN will be in addition to the current DNS. forever. That is, IDN will be in addition to the current DNS.
7.2 trans-2: Transition period 7.2 trans-2: Transition period
In this proposal, IDN will be used at the same time as the current DNS In this proposal, IDN will be used at the same time as the current DNS
for a specified period of time, after which only IDN will exist. That for a specified period of time, after which only IDN will exist. That
is, IDN will replace the current DNS. is, IDN will replace the current DNS.
8. Root server considerations 8. Root server considerations
DNS root servers receive all requests for top-level domains that not in DNS root servers receive all requests for top-level domains that are not
the local DNS cache. They are critical to the Internet. Care must be in the local DNS cache. They are critical to the Internet. Care must be
taken to ensure that root servers will not be affected by new mechanisms taken to ensure that root servers will not be affected by new mechanisms
introduced. introduced.
Any IDN proposal that includes a binary encoding will have an impact on Any IDN proposal that includes a binary encoding will have an impact on
the root servers. The binary requests will affect the root servers the root servers. The binary requests will affect the root servers
because the current root server software is designed to handle current because the current root server software is designed to handle current
host names. Further, the root zone files which contain ccTLDs and gTLDs host names. Further, the root zone files which contain ccTLDs and gTLDs
would have to support binary domain names and possibly binary host names would have to support binary domain names and possibly binary host names
for NS records. Because all the root servers are equivalent, they would for NS records. Because all the root servers are equivalent, they would
have to be synchronized to support the binary domain names at the same have to be synchronized to support the binary domain names at the same
skipping to change at line 581 skipping to change at line 612
pre-release versions of this document. pre-release versions of this document.
12. References 12. References
[BLOCK-NAMES] Unicode Consortium, [BLOCK-NAMES] Unicode Consortium,
<ftp://ftp.unicode.org/Public/UNIDATA/Blocks.txt>. <ftp://ftp.unicode.org/Public/UNIDATA/Blocks.txt>.
[DUERST] Character Normalization in IETF Protocols, [DUERST] Character Normalization in IETF Protocols,
draft-duerst-i18n-norm-03 draft-duerst-i18n-norm-03
[HOFFMAN] Compatible Internationalized Domain Names Using Compression,
draft-hoffman-idn-cidnuc-03
[IDN-REQ] Requirements of Internationalized Domain Names, [IDN-REQ] Requirements of Internationalized Domain Names,
draft-ietf-idn-requirements-02 draft-ietf-idn-requirements-02
[IDNE] Internationalized domain names using EDNS (IDNE),
draft-ietf-idn-idne-01
[KWAN] Using the UTF-8 Character Set in the Domain Name System, [KWAN] Using the UTF-8 Character Set in the Domain Name System,
draft-skwan-utf8-dns-03 draft-skwan-utf8-dns-03
[OSCARSSON] Internationalisation of the Domain Name Service, [RACE] RACE: Row-based ASCII Compatible Encoding for IDN,
draft-oscarsson-i18ndns-00 draft-ietf-idn-race-00
[RFC2277] IETF Policy on Character Sets and Languages, RFC 2277 [RFC2277] IETF Policy on Character Sets and Languages, RFC 2277
[RFC2279] UTF-8, a transformation format of ISO 10646, RFC 2279 [RFC2279] UTF-8, a transformation format of ISO 10646, RFC 2279
[RFC2671] Extension Mechanisms for DNS (EDNS0), RFC 2671 [RFC2671] Extension Mechanisms for DNS (EDNS0), RFC 2671
[SENG] UTF-5, a transformation format of Unicode and ISO 10646, [SENG] UTF-5, a transformation format of Unicode and ISO 10646,
draft-jseng-utf5-01 draft-jseng-utf5-01
[UDNS] Using the Universal Character Set in the Domain Name System
(UDNS), draft-ietf-idn-udns-00
[UTR15] Unicode Normalization Forms, Unicode Technical Report #15 [UTR15] Unicode Normalization Forms, Unicode Technical Report #15
A. Author Contact A. Differences Between -00 and -01 Drafts
Throughout: Changed references from [HOFFMAN] to [RACE].
Throughout: Changed references from [OSCARSSON] to [UDNS].
Throughout: Added [IDNE].
Removed section 1.2.
3.2.3: Updated to mention [UDNS].
3.2.4: Updated with [IDNE], changed "EDNS0" to "EDNS", and reworded.
4.1.2: Added Ethiopic to the list of scripts that require two octets per
character.
4.1.3: Removed reference to [OSCARSSON] because that is no longer in the
[UDNS] draft.
4.2.2.1: Removed reference to [OSCARSSON] because that is no longer in
the [UDNS] draft.
6.1.1: Reworded first sentence.
6.3: Added entire section and subsections.
8: Fixed typo in first sentence.
B. Author Contact
Paul Hoffman Paul Hoffman
IMC & VPNC IMC & VPNC
127 Segre Place 127 Segre Place
Santa Cruz, CA 95060 Santa Cruz, CA 95060
phoffman@imc.org or paul.hoffman@vpnc.org phoffman@imc.org or paul.hoffman@vpnc.org
 End of changes. 27 change blocks. 
56 lines changed or deleted 119 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/