Network Working Group C. Malamud
Internet-Draft Memory Palace Press
Expires: June 1, 2005 December 1, 2004
The iam Service
draft-malamud-iam-service-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 1, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes the iam service, an alternative to WHOIS.
Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Malamud Expires June 1, 2005 [Page 1]
Internet-Draft iam December 2004
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Service Definition . . . . . . . . . . . . . . . . . . . . . . 5
3. Service Parameters . . . . . . . . . . . . . . . . . . . . . . 6
4. Discussion (Non-Normative) . . . . . . . . . . . . . . . . . . 10
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. ICANN Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 15
8.2 Informative References . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
A. Reference Implementation (Non-Normative) . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 21
Malamud Expires June 1, 2005 [Page 2]
Internet-Draft iam December 2004
1. Overview
The WHOIS Protocol is used to provide "information about registered
domain names" in "human-readable format."[RFC3912] Provision of
WHOIS service by registries and registrars is required by ICANN under
a mandatory operating agreement.[ICANN-Registrar]
Although the WHOIS service provides a simple unformatted interface
for the end user, a variety of efforts are used to control the
population of that information in databases through a complex
interaction between domain name registrants, registrars, and
registries.[RFC3707]
The purpose of mandating accurate WHOIS information in domain name
registries is to provide a contact mechanism and accountability. As
such ICANN in their WDRP regulations mandate registrars to remind
registrants "that provision of false Whois information can be grounds
for cancellation of their domain name registration."[WDRP] The
monetary value of the compilation of registrants is a tempting target
for direct marketing and ICANN has regulated such use in the
WMRP.[WMRP]
Accountability of registrants coupled with restrictions on bulk
access are thus design goals which are attempted to be met by the
WHOIS service. Unfortunately, a complex set of protocols is used to
govern the interaction of registrants, registrars, registries, and
regulators. This document proposes that this chain of protocols is a
good example of "the rise of the middle" and proposes an alternative
service based on end-to-end design principles.[RFC3724]
Three sets of requirements are intermingled:
1. A method for registrants to provide registrars their contact
information for use in registering a domain name and for
operational purposes such as maintaining host records, updating
billing information, or confirming transfers. The current
EPP/CRISP efforts address this requirement.
2. Authorized use of the compilation of names in a registry appears
to be in the purview of ICANN and TLD administrators.
Unauthorized use of the compilation has proven to be a continuing
problem with the current WHOIS-based architecture.
3. A method for members of the public to determine who owns a domain
name and how to contact them.
The centralized approach to meeting requirement 3, public access, has
resulted in unauthorized use of the compilation in requirement 2.
Indeed, one could argue that use of a compilation for further
marketing of services is not a requirement at all and could be
eliminated or moved into a more limited role. However, that issue is
Malamud Expires June 1, 2005 [Page 3]
Internet-Draft iam December 2004
beyond the scope of the present document.
Malamud Expires June 1, 2005 [Page 4]
Internet-Draft iam December 2004
2. Service Definition
Per the requirements of [RFC3403] the iam service is defined as an
NAPTR-based application. The service provides for a single
NAPTR-based lookup on a domain name, returning a URI. The "first
known domain-name" is thus derived as direct input from the user.
The allowed values of the NAPTR fields are as follows:
o The Order and Preference fields SHALL be used as specified in
[RFC3403].
o The Flags field SHALL always contain the value "U", which
signifies that the record is terminal and contains a URI.
o The Service field SHALL always start with the string "iam+",
followed by exactly one additional service parameter, currently
limited to values "opaque" and "rfc2629" as specified in Section
3.
o The Regular Expression field SHALL contain a regexp expression
which will transform the lookup key into a valid URI as further
specified in Section 3.
o The Replacement field SHALL contain a valid domain name and is not
used in this application. The character "." MAY be used as the
string.
The expected output of the single rule chosen is the terminal rewrite
rule which is always a URL.
Malamud Expires June 1, 2005 [Page 5]
Internet-Draft iam December 2004
3. Service Parameters
An iam application retrieves all NAPTR records conforming to the
lookup key, and MUST discard all records where the initial service
parameter is not "iam".
The field MUST contain a second service parameter, which contains a
valid "parameter type" contained in the iam Services Registry as
defined in Section 7.1.
Two "parameter type" values are defined in this document:
o "opaque"
o "rfc2629"
3.1 The iam+opaque Service Parameter
If the service parameter field contains "iam+opaque", the regular
expression will result in a valid URI, limited to the following URI
schemes:
o "http" as specified in [RFC2616].
o "https" as specified in [RFC2660].
o "ftp" as specified in [RFC0959].
The content of the document retrieved from the URI is not specified
in this document. Designers of documents which are retrieved using
the iam service are encouraged to vary the content and format of
these documents. Documents should be easily viewable by human
beings, but there is no requirement for structure that would assist
automated applications in harvesting contact information.
A simple example is as follows. If the registrant of the
"example.com" domain wishes to provide contact information using the
iam service, the first step is to construct a valid NAPTR record:
example.com.
;; order pref flags service
IN NAPTR 100 10 "U" "iam+opaque"
"/^.*$/http:\/\/example.com\/contact.html/" .
;; regexp replacement
The regular expression will always resolve to the URI
"http://example.com/contact.html". The content of this document
might be the following:
Malamud Expires June 1, 2005 [Page 6]
Internet-Draft iam December 2004
<html>
<head>
<title>Welcome to my contact information</title>
</head>
<body>
<p>
Hi. My name is John Doe and I live here at example.com.
If you need to reach me, my username is jdoe and my isp
is example.net. My favorite color is blue and you can
find more information about me
<a href="http://example.com/moreinfo.html">here</a>
</p>
</body>
</html>
3.2 The iam+rfc2629 Service Parameter
If the service parameter field contains "iam+rfc2629", the regular
expression will result in a valid URI, which will return a document
that conforms to the "<reference>" as specified in [RFC2629]. As
with the "iam+opaque", the set of NAPTR records MUST contain at least
one of the "http", "https", or "ftp" URI schemes, but MAY include
records of equal "order" with other URI schemes. (Simply put, if you
offer an "rsync" resource record, you must also have a resource
record with a "basic" URI scheme.)
An example of a NAPTR resource record of this type is:
example.com.
;; order pref flags service
IN NAPTR 100 10 "U" "iam+rfc2629"
"/^.*$/https:\/\/example.com\/contact.xml/" .
;; regexp replacement
The regular expression will always resolve to the URI
"http://example.com/contact.xml". The content of this document might
be the following:
Malamud Expires June 1, 2005 [Page 7]
Internet-Draft iam December 2004
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='required'>
<front>
<title>My Contact Information</title>
<author initials='J.' surname='Doe' fullname='John Doe'>
<organization>unaffiliated person</organization>
<address>
<email>jdoe@example.net</email>
</address>
</author>
<date year='2004' day='1' month='November' />
<abstract>
<t>
Hi -
Welcome to my contact information!
</t>
</abstract>
</front>
<seriesInfo name="Favorite Color:" value="Blue" />
<format type='More Info'
target='http://example.com/moreinfo.html' />
</reference>
[RFC2629] requires an anchor attribute on the "<reference>" element,
but this attribute is not used by the iam service. The "<date>"
element SHOULD contain the date this document was last updated. The
"<abstract>", "<seriesInfo>", and "<format>" elements MAY be used at
the discretion of the document designer.
3.3 Multiple NAPTR Responses
If a lookup results in multiple NAPTR resource records, an
application SHOULD use the following rules in sequence to choose one
record:
1. The application MUST discard all resource records where the first
characters of the service parameter are not "iam".
2. The application MAY discard all resource records based on the
second service parameter. For example, if some resource records
are returned with a service parameter field of "iam+rfc2629" and
others have "iam+opaque", the application MAY choose which set to
process.
3. The application MUST discard all resource records with an Order
field higher than the minimum value of the remaining set of
resource records.
4. The application SHOULD choose a resource record with a lower
Preference value but MAY choose a record with a higher preference
value.
Malamud Expires June 1, 2005 [Page 8]
Internet-Draft iam December 2004
3.4 Use of DNSSEC
An application SHOULD verify all DNSSEC signatures as the records are
retrieved and SHOULD discard all resource records that fail the
verification procedures as outlined in the DNSSEC documents.
Malamud Expires June 1, 2005 [Page 9]
Internet-Draft iam December 2004
4. Discussion (Non-Normative)
Upon being presented with an early draft of this document, Paul Vixie
commented that "naptr is pretty hard compared to srv, don't you
think?" Upon further prodding he proposed the following solution
using the SRV[RFC2782] resource record:
$ORIGIN example.com.
_whois._tcp SRV 0 1 23 myisp.example.net.
SRV 0 3 23 myownbox.example.com.
This solution preserves the existing investment in the WHOIS
protocol, while still allowing a domain name registrant to specify
the location of the relevant WHOIS servers and thus spares the
end-user a three-step lookup consisting of:
1. Find the registry for the TLD in question.
2. Query the registry.
3. Query the registrar.
The SRV-based approach thus has many of the same attributes as the
"iam+rfc2629" of allowing the domain registrant to present structured
text with contact information.
On the other hand, one of the attractive attributes of the
"iam+opaque" service parameter is the very fact that structured text
is not necessarily present and thus discourages automated harvesting
of contact information. The iam service also eliminates the need for
a WHOIS server, a service that may not be present in many common
web-hosting environments, which typically offer a LAMP service
(Linux, Apache, MySQL, PhP).
One argument for the current system of WHOIS information furnished
through the registrant/registrar/registry chain is that this somehow
provides more accountability and more accurate information. However,
repeated investigations have shown that the present system does not
do anything to promote such accuracy.[ICANN-Integrity]
Creation and registration of a domain name has become confused under
the current system with a perceived need for registries and
registrants to publish contact information for end users. Allowing
domain registrants to provide their own public contact information is
a more flexible approach, and can draw on DNSSEC, server
certificates, and other existing authentication mechanisms instead of
making the domain registration process bear that additional
publication burden.
Malamud Expires June 1, 2005 [Page 10]
Internet-Draft iam December 2004
5. Acknowledgments
The author would like to thank the following individuals for comments
and suggestions received: Eric Rescorla and Paul Vixie. As always,
all errors & omissions remain the responsibility of the author.
Malamud Expires June 1, 2005 [Page 11]
Internet-Draft iam December 2004
6. Security Considerations
This application is only as secure as the DNS on which it is based.
The use of DNSSEC as defined in [I-D.ietf-dnsext-dnssec-intro] and
related specifications is thus highly recommended in conjunction with
this application. In particular, use of the "https" URL scheme
without the use of DNSSEC makes the unwarranted illusion of
authenticity and the possibility of active attacks a serious concern.
Malamud Expires June 1, 2005 [Page 12]
Internet-Draft iam December 2004
7. ICANN Considerations
7.1 iam Services Registry
As described in Section 3, a new registry is created which lists
valid entries for the second service parameters entry in the NAPTR
resource record.
The registry type, is "Specification Required", meaning that the
field "must be documented in an RFC or other permanent and readily
available reference, in sufficient detail so that interoperability
between independent implementations is possible."[RFC2434]
The registry contains three fields:
o "service parameter" contains an alphanumeric string.
o "description" contains a short verbal description.
o "reference" contains a reference to an RFC or other archival
document meeting the "Specification Required" standard.
The initial values of the registry are:
Service Parameter Description Reference
================= ================================ =========
opaque The resulting URI has no [RFCXXXX]
predefined structure.
rfc2629 The resulting URI conforms to [RFCXXXX]
the <reference> as defined
in RFC2629.
7.2 URL Scheme Registration Template
Per the requirements of [RFC2717], the "iam" URL scheme is registered
under the IETF tree, and should be added to the Official IANA
Registry of URI Schemes[IANA-URI] as follows:
Scheme Name Description Reference
----------- ----------------------------------------- ---------
iam iam service [RFCXXXX]
The syntax of the scheme, defined as a subset of the generic
components of [RFC2396], modified to conform to [RFC2234] is as
follows:
Malamud Expires June 1, 2005 [Page 13]
Internet-Draft iam December 2004
iam = "iam:" netpath
netpath = "//" authority
authority = host
host = hostname
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum
toplabel = alpha / alpha *( alphanum / "-" ) alphanum
alpha = lowalpha / upalpha
; note: domain names are not case sensitive
lowalpha = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" /
"j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" /
"s" / "t" / "u" / "v" / "w" / "x" / "y" / "z"
upalpha = "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" /
"J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" /
"S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z"
digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
"8" / "9"
alphanum = alpha / digit
Additional Considerations Per the Requirements of the Registration
Template:
o Character encoding considerations are based on the underlying DNS.
In particular, non-USASCII names are based on the IDN standards as
detailed in [RFC3490], [RFC3491], and [RFC3492].
o The intended usage of this application is to furnish contact
information for a domain name.
o Applications and/or protocols which will use this URL scheme name
are client applications which provide an alternative to
WHOIS-based domain name lookup.
o Any interoperability considerations are based on the underlying
DNS.
o Security considerations are discussed in Section 6 of this
document.
o Contact information is included in this document.
o Change control of this scheme will be with the IETF.
Malamud Expires June 1, 2005 [Page 14]
Internet-Draft iam December 2004
8. References
8.1 Normative References
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD
9, RFC 959, October 1985.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC2660] Rescorla, E. and A. Schiffman, "The Secure HyperText
Transfer Protocol", RFC 2660, August 1999.
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL
Scheme Names", BCP 35, RFC 2717, November 1999.
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", RFC
3403, October 2002.
[RFC3490] Faltstrom, P., Hoffman, P. and A. Costello,
Malamud Expires June 1, 2005 [Page 15]
Internet-Draft iam December 2004
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", RFC
3491, March 2003.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, March 2003.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C. and S. Wu,
"Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647,
November 2003.
[RFC3707] Newton, A., "Cross Registry Internet Service Protocol
(CRISP) Requirements", RFC 3707, February 2004.
[RFC3724] Kempf, J., Austein, R. and IAB, "The Rise of the Middle
and the Future of End-to-End: Reflections on the Evolution
of the Internet Architecture", RFC 3724, March 2004.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
September 2004.
8.2 Informative References
[I-D.ietf-dnsext-dnssec-intro]
Arends, R., Austein, R., Massey, D., Larson, M. and S.
Rose, "DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-13 (work in progress),
October 2004.
[IANA-URI]
IANA, "Official IANA Registry of URI Schemes", October
2004, <http://www.iana.org/assignments/uri-schemes>.
[ICANN-Integrity]
Subcommittee on Courts, the Internet, and Intellectual
Property, "Accuracy and Integrity of the Whois Database",
Committee on the Judiciary, U.S. House of Representatives,
Serial No. 70, May 2002,
<http://www.house.gov/judiciary/79752.pdf>.
[ICANN-Registrar]
ICANN, "Registrar Accreditation Agreement", Ammended: 25
November 2002, Ammended: 23 January 2003, Ammended: 3
Malamud Expires June 1, 2005 [Page 16]
Internet-Draft iam December 2004
April 2003, May 2001,
<http://www.icann.org/registrars/ra-agreement-17may01.htm>
.
[WDRP] ICANN, "Whois Data Reminder Policy (WDRP)", June 2003,
<http://www.icann.org/registrars/wdrp.htm>.
[WMRP] ICANN, "Whois Marketing Restriction Policy Policy (WMRP)",
August 2004, <http://www.icann.org/registrars/wmrp.htm>.
Author's Address
Carl Malamud
Memory Palace Press
PO Box 300
Sixes, OR 97476
US
EMail: carl@media.org
Malamud Expires June 1, 2005 [Page 17]
Internet-Draft iam December 2004
Appendix A. Reference Implementation (Non-Normative)
A set of NAPTR records have been installed in the "simians.net"
subdomain and can be retrieved using "dig" or other DNS utilities:
[carl@example.com] csh% dig simians.net naptr
;; QUESTION SECTION:
;simians.net. IN NAPTR
;; ANSWER SECTION:
simians.net. 86400
IN NAPTR 1 1 "U" "iam+opaque"
"!^.*$!http://simians.net/contact.html!" .
simians.net. 86400
IN NAPTR 1 1 "U" "iam+invalid"
"!^.*$!http://simians.net/contact.html!" .
simians.net. 86400
IN NAPTR 1 1 "U" "sip+invalid"
"!^.*$!http://simians.net/contact.html!" .
simians.net. 86400
IN NAPTR 1 2 "U" "iam+opaque"
"!^.*$!http://simians.net/contact.html!" .
simians.net. 86400
IN NAPTR 2 1 "U" "iam+opaque"
"!^.*$!http://simians.net/contact.html!" .
A simple utility written in PERL accepts a lookup key and returns a
URL using the specifications in this document:
#!/usr/bin/perl
use strict;
# http://www.net-dns.org/
use Net::DNS;
my $target = $ARGV[0];
&usage()
if ( $target eq "" )
|| ( $target !~ /^[a-zA-Z][a-zA-Z.-]*/ )
|| ( $target =~ /help/i );
my $res = Net::DNS::Resolver->new;
my $query = $res->query( "$target", "NAPTR" );
if ( !$query ) {
warn "Query failed: ", $res->errorstring, "\n";
exit;
}
my @rr = $query->answer;
Malamud Expires June 1, 2005 [Page 18]
Internet-Draft iam December 2004
my $order = 9999999;
my $pref = 9999999;
my $usethis;
foreach my $record (@rr) {
next unless $record->type eq "NAPTR";
# insert DNSSEC verification here
next unless $record->service =~ /iam\+(opaque|rfc2629)/;
next unless $record->flags =~ /u/i;
if ( $record->order < $order ) { $usethis = $record; }
if ( $record->preference < $pref ) { $usethis = $record; }
next;
}
if ($usethis) {
# apply the regexp
my $regex = $usethis->regexp;
my $delim = substr( $regex, 0, 1 );
my ( $left, $right );
$left = $regex;
$right = $regex;
$left =~ s/^$delim(.*)$delim(.*)$delim$/$1/e;
$right =~ s/^$delim(.*)$delim(.*)$delim$/$2/e;
$target =~ s/$left/$right/e;
print $target ;
}
else {
warn "Query failed. No applicable results found.\n";
}
exit(0);
sub usage {
print STDERR "Usage: $0 domain_name\n";
exit;
}
Running the code as input to the lynx browser, yields the following
results:
Malamud Expires June 1, 2005 [Page 19]
Internet-Draft iam December 2004
[desktop:~carl/Documents/DNS] carl# lynx -source `./iam.pl simians.net`
<html>
<head>
<title>Meet the Monkeys</title>
</head>
<body>
<center>
<a href="monkey.mp3">
<img alt="bouncy monkey logo"
src="images/monkey_fpo.gif" border="0" />
<br />
Click Here to Hear My Info
</a>
</center>
</body>
</html>
[desktop:~carl/Documents/DNS] carl#
Malamud Expires June 1, 2005 [Page 20]
Internet-Draft iam December 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Malamud Expires June 1, 2005 [Page 21]