draft-ietf-urn-http-conv-00.txt   rfc2169.txt 
INTERNET DRAFT Ron Daniel Network Working Group R. Daniel
draft-ietf-urn-http-conv-00.txt Los Alamos National Laboratory Request for Comments: 2169 Los Alamos National Laboratory
21 Nov, 1996 Category: Experimental June 1997
Conventions for the Use of HTTP for URN Resolution A Trivial Convention for using HTTP in URN Resolution
Status of this Memo Status of this Memo
=================== ===================
This document is an Internet-Draft. Internet-Drafts are working This memo defines an Experimental Protocol for the Internet
documents of the Internet Engineering Task Force (IETF), its community. This memo does not specify an Internet standard of any
areas, and its working groups. Note that other groups may also kind. Discussion and suggestions for improvement are requested.
distribute working documents as Internet-Drafts. Distribution of this memo is unlimited.
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.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
This draft expires 21 May, 1997.
Abstract: Abstract:
========= =========
The URN-WG was formed to specify persistent, location-independent names The Uniform Resource Names Working Group (URN-WG) was formed to
for network accessible resources, and resolution mechanisms to retrive specify persistent, location-independent names for network accessible
the resources given such a name. At this time the URN-WG is considering resources, as well as resolution mechanisms to retrieve the resources
one particular resolution mechanism, the NAPTR proposal [1]. That proposal given such a name. At this time the URN-WG is considering one
does not get the client software all the way from the URN to the resource. particular resolution mechanism, the NAPTR proposal [1]. That
Instead, it gets the client from a URN to a "resolver", which is a system proposal specifies how a client may find a "resolver" for a URN. A
that can then tell the client where the resource is. The NAPTR draft resolver is a database that can provide information about the
defines a "resolution protocol" to be the protocol used to speak to a resource identified by a URN, such as the resource's location, a
resolver in order to obtain the resource, its location(s), or other bibliographic description, or even the resource itself. The protocol
information about the resource. The NAPTR proposal allows different used for the client to communicate with the resolver is not specified
resolution protocols to be used for commuicating with resolvers. in the NAPTR proposal. Instead, the NAPTR resource record provides a
field that indicates the "resolution protocol" and "resolution
service requests" offered by the resolver.
This draft establishes conventions for encoding URN resolution requests This document specifies the "THTTP" resolution protocol - a trivial
and responses in HTTP 1.0 (and 1.1) requests and responses. The primary convention for encoding resolution service requests and responses as
goal of this draft is to define a convention that is simple to implement HTTP 1.0 or 1.1 requests and responses. The primary goal of THTTP is
and will allow existing HTTP servers to easily add support for URN to be simple to implement so that existing HTTP servers may easily
resolution. We expect that the resolution databases that arise will be add support for URN resolution. We expect that the databases used by
useful when more sophisticated resolution protocols are developed later. early resolvers will be useful when more sophisticated resolution
protocols are developed later.
1.0 Introduction: 1.0 Introduction:
================== ==================
The NAPTR draft[1] describes a way of using DNS to locate resolvers for The NAPTR specification[1] defined a new DNS resource record which
URIs. That draft provides places to specify the "resolution protocol" may be used to discover resolvers for Uniform Resource Identifiers.
spoken by the resolver, as well as the "resolution services" it offers. That resource record provides the "services" field to specify the
As of this writing, the "resolution protocols" allowed by the NAPTR draft "resolution protocol" spoken by the resolver, as well as the
are HTTP, RCDS, HDL, and RWHOIS. (That list is expected to grow over time). "resolution services" it offers. Resolution protocols mentioned in
The NAPTR draft also lists a variety of resolution services, such that specification are Z3950, THTTP, RCDS, HDL, and RWHOIS. (That
as N2L (given a URN, return a URL); N2R (Given a URN, return the named list is expected to grow over time). The NAPTR specification also
resource), etc. This draft specifies the conventions to follow to lists a variety of resolution services, such as N2L (given a URN,
encode resolution service requests in the HTTP protocol, allowing return a URL); N2R (Given a URN, return the named resource), etc.
widely available HTTP daemons to serve as URN resolvers.
The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1 [3] This document specifies the "THTTP" (Trivial HTTP) resolution
specifications. protocol. THTTP is a simple convention for encoding resolution
service requests and responses as HTTP 1.0 or 1.1 requests and
responses. The primary goal of THTTP is to have a URN resolution
protocol that can easily be added to existing HTTP daemons. Other
resolution protocols are expected to arise over time, so this
document serves a secondary purpose of illustrating the information
that needs to be specified for a URN resolution protocol. One of the
resolution protocols we expect to be developed is an extension of
HTTP with new methods for the resolution services. Therefore, we use
"THTTP" as the identifier for this protocol to leave "HTTP" for later
developments.
The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1
[3] specifications. Implementors of this specification should be
familiar with CGI scripts, or server-specific interfaces, for
database lookups.
2.0 General Approach: 2.0 General Approach:
===================== =====================
The general approach used to encode resolution service requests in HTTP The general approach used to encode resolution service requests in
is quite simple: THTTP is quite simple:
GET /uri-res/<service>/<uri> HTTP/1.0
For example, if we have the URN "cid:foo@huh.com" and want a URL,
we would send the request:
GET /uri-res/N2L/cid:foo@huh.com HTTP/1.0 GET /uri-res/<service>?<uri> HTTP/1.0
Because of the character set limitations on URIs, we might wish to For example, if we have the URN "urn:foo:12345-54321" and want a URL,
encode the '@' character as its hex equivalent, thus the request would be we would send the request:
GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.0 GET /uri-res/N2L?urn:foo:12345-54321 HTTP/1.0
The request could also be encoded as an HTTP 1.1 request. This would look The request could also be encoded as an HTTP 1.1 request. This would
like: look like:
GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.1 GET /uri-res/N2L?urn:foo:12345-54321 HTTP/1.1
Host: <whatever host we are sending the request to> Host: <whatever host we are sending the request to>
Handling these requests on the server side is easy to implement in a Responses from the HTTP server follow standard HTTP practice. Status
number of ways. The N2L request could be handled by a CGI script that codes, such as 200 (OK) or 404 (Not Found) shall be returned. The
took the incoming URN, looked it up in a database, and returned the URL normal rules for determining cachability, negotiating formats, etc.
as an HTTP redirect. Service requests like N2R or N2C could be set up apply.
so that the daemon answered the request by returning files out of N2R/
and N2C/ directories, or they could be handled by a script.
One caveat should be kept in mind. The "urn:" prefix is still the Handling these requests on the server side is easy to implement using
subject of controversy, so some URN documents advocate treating it CGI or other, server-specific, extension mechanisms. CGI scripts
as optional. HTTP resolvers MUST return identical results for URIs will see the incoming URI in the QUERY_STRING environment variable.
that do and do not contain the "urn:" prefix. For example, the two Any %encoded characters in the URN will remain in their %encoded
request below must return identical results: state in that string. The script can take the URN, look it up in a
GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.0 database, and return the requested information.
GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.0
Responses from the HTTP server follow standard HTTP practice. Status One caveat should be kept in mind. The URN syntax document [4]
codes, such as 200 (OK) or 404 (Not Found) shall be returned. discusses the notion of lexical equivalance and requires that
The normal rules for determining cachability, negotiating formats, etc. resolvers return identical results for URNs that are lexically
apply. equivalent. Implementors of this specification must be careful to
obey that rule. For example, the two requests below MUST return
identical results, since the URNs are lexically equivalent.
GET /uri-res/N2L?urn:cid:foo@huh.com HTTP/1.0
GET /uri-res/N2L?URN:CID:foo@huh.com HTTP/1.0
3.0 Service-specific details: 3.0 Service-specific details:
============================= =============================
This section goes through the various resolution services established This section goes through the various resolution services established
in the URN Framework draft [4] and states how to encode each of them, in the URN services document [5] and states how to encode each of
how the results should be returned, and any special status codes that them, how the results should be returned, and any special status
are likely to arise. codes that are likely to arise.
Unless stated otherwise, the HTTP requests are formed according to Unless stated otherwise, the THTTP requests are formed according to
the simple convention above, either for HTTP/1.0 or HTTP/1.1. The response the simple convention above, either for HTTP/1.0 or HTTP/1.1. The
is assumed to be an entity with normal headers and body unless stated response is assumed to be an entity with normal headers and body
otherwise. (N2L is the only request that does not return a body). unless stated otherwise. (N2L is the only request that need not
return a body).
3.1 N2L (URN to URL): 3.1 N2L (URN to URL):
---------------------- ----------------------
The request is encoded as above. The URL MUST be returned in a Location: The request is encoded as above. The URL MUST be returned in a
header for the convienience of the most common case of wanting the resource. Location: header for the convienience of the user in the most common
A 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the case of wanting the resource. If the lookup is successful, a 30X
303 status code. HTTP/1.0 clients should be sent the 302 (Moved temporarily) status line SHOULD be returned. HTTP/1.1 clients should be sent the
status code unless the resolver has particular resons for using 301 303 status code. HTTP/1.0 clients should be sent the 302 (Moved
(moved permanently) or 304 (not modified) codes. temporarily) status code unless the resolver has particular reasons
for using 301 (moved permanently) or 304 (not modified) codes.
Note that access controls may be applied to this, or any other,
resolution service request. Therefore the 401 (unauthorized) and 403
(forbidden) status codes are legal responses. The server may wish to
provide a body in the response to explain the reason for refusing
access, and/or to provide alternate information about the resource,
such as the price it will cost to obtain the resource's URL.
3.2 N2Ls (URN to URLs): 3.2 N2Ls (URN to URLs):
------------------------ ------------------------
The request is encoded as above. The result is a list of 0 or The request is encoded as above. The result is a list of 0 or more
more URLs. The Internet Media Type (aka ContentType) of the result URLs. The Internet Media Type (aka ContentType) of the result may be
may be negotiated using standard HTTP mechanisms if desired. At a negotiated using standard HTTP mechanisms if desired. At a minimum
minimum the resolver should support the text/uri-list media type. the resolver should support the text/uri-list media type. (See
(See Appendix A for the definition of this media type). That media Appendix A for the definition of this media type). That media type is
type is suitable for machine-processing of the list of URLs. Resolvers suitable for machine-processing of the list of URLs. Resolvers may
may also return the results as text/html, text/plain, or any other also return the results as text/html, text/plain, or any other media
media type they deem suitable. type they deem suitable.
No matter what the particular media type, the result MUST be a list No matter what the particular media type, the result MUST be a list
of the URLs which may be used to obtain an instance of the resource of the URLs which may be used to obtain an instance of the resource
identified by the URN. All URIs shall be encoded according to the identified by the URN. All URIs shall be encoded according to the URI
URI specification [5]. specification [6].
If the client has requested the result be returned as text/html or If the client has requested the result be returned as text/html or
application/html, the result should be encoded as: application/html, the result should be a valid HTML docment
<UL> containing the fragment:
<LI><A HREF="...url 1...">...url 1...</A> <UL>
<LI><A HREF="...url 2...">...url 2...</A> <LI><A HREF="...url 1...">...url 1...</A>
etc. <LI><A HREF="...url 2...">...url 2...</A>
</UL> etc.
where the strings ...url n... are replaced by the n'th URL in the list. </UL>
where the strings ...url n... are replaced by the n'th URL in the
list.
3.3 N2R (URN to Resource): 3.3 N2R (URN to Resource):
--------------------------- ---------------------------
The request is encoded as above. The resource is returned using The request is encoded as above. The resource is returned using
standard HTTP mechanisms. The request may be modified using the standard HTTP mechanisms. The request may be modified using the
Accept: header as in normal HTTP to specify that the result Accept: header as in normal HTTP to specify that the result be given
be given in a preferred Internet Media Types. in a preferred Internet Media Type.
3.4 N2Rs (URN to Resources): 3.4 N2Rs (URN to Resources):
----------------------------- -----------------------------
This resolution service returns multiple instances of a resource, This resolution service returns multiple instances of a resource, for
for example, GIF and JPEG versions of an image. The judgment about example, GIF and JPEG versions of an image. The judgment about the
the resources being "the same" resides with the naming authority that resources being "the same" resides with the naming authority that
issued the URN. issued the URN.
The request is encoded as above. The result shall be a MIME The request is encoded as above. The result shall be a MIME
multipart/alternative message with the alternative versions of the multipart/alternative message with the alternative versions of the
resource in seperate body parts. If there is only one version of resource in seperate body parts. If there is only one version of the
the resource identified by the URN, it MAY be returned without the resource identified by the URN, it MAY be returned without the
multipart/alternative wrapper. Resolver software SHOULD look at the multipart/alternative wrapper. Resolver software SHOULD look at the
Accept: header, if any, and only return versions of the resource Accept: header, if any, and only return versions of the resource that
that are acceptable according to that header. are acceptable according to that header.
3.5 N2C (URN to URC): 3.5 N2C (URN to URC):
---------------------- ----------------------
URCs (Uniform Resource Characteristics) are descriptions of other URCs (Uniform Resource Characteristics) are descriptions of other
resources. This request allows us to obtain a description of the resources. This request allows us to obtain a description of the
resource identified by a URN, as opposed to the resource itself. resource identified by a URN, as opposed to the resource itself. The
The description might be a bibliographic citation, a digital signature, description might be a bibliographic citation, a digital signature, a
a revision history, etc. This draft does not specify the content of revision history, etc. This document does not specify the content of
any response to a URC request. That content is expected to vary from any response to a URC request. That content is expected to vary from
one resolver to another. one resolver to another.
The format of any response to a N2C request MUST be communicated using the The format of any response to a N2C request MUST be communicated
ContentType header, as is standard HTTP practice. The Accept: header using the ContentType header, as is standard HTTP practice. The
SHOULD be honored. Accept: header SHOULD be honored.
3.6 N2Ns (URN to URNs): 3.6 N2Ns (URN to URNs):
------------------------ ------------------------
While URNs are supposed to identify one and only one resource, that While URNs are supposed to identify one and only one resource, that
does not mean that a resource may have one and only one URN. For does not mean that a resource may have one and only one URN. For
example, consider a resource that has something like example, consider a resource that has something like "current-
"current-weather-map" for one URN and "weather-map-for-datetime-x" for weather-map" for one URN and "weather-map-for-datetime-x" for another
another URN. The N2Ns service request lets us obtain lists of URNs that URN. The N2Ns service request lets us obtain lists of URNs that are
are believed equivalent at the time of the request. As the weathermap believed equivalent at the time of the request. As the weathermap
example shows, some of the equivalances will be transitory, so the example shows, some of the equivalances will be transitory, so the
standard HTTP mechanisms for communicating cachability MUST be honored. standard HTTP mechanisms for communicating cachability MUST be
honored.
The request is encoded as above. The result is a list of all the The request is encoded as above. The result is a list of all the
URNs, known to the resolver, which identify the same resource as the URNs, known to the resolver, which identify the same resource as the
input URN. The result shall be encoded as for the N2Ls request input URN. The result shall be encoded as for the N2Ls request above
above (text/uri-list unless specified otherwise by an Accept: header). (text/uri-list unless specified otherwise by an Accept: header).
3.7 L2Ns (URL to URNs): 3.7 L2Ns (URL to URNs):
---------------------- ----------------------
The request is encoded as above. The response is a list of any URNs The request is encoded as above. The response is a list of any URNs
known to be assigned to the resource at the given URL. The result known to be assigned to the resource at the given URL. The result
shall be encoded as for the N2Ls and N2Ns requests. shall be encoded as for the N2Ls and N2Ns requests.
3.8 L2Ls (URL to URLs): 3.8 L2Ls (URL to URLs):
------------------------ ------------------------
The request is encoded as described above. The result is a list of The request is encoded as described above. The result is a list of
all the URLs that the resolver knows are associated with the resource all the URLs that the resolver knows are associated with the resource
located by the given URL. This is encoded as for the N2Ls, N2Ns, and L2Ns located by the given URL. This is encoded as for the N2Ls, N2Ns, and
requests. L2Ns requests.
3.9 L2C (URL to URC): 3.9 L2C (URL to URC):
---------------------- ----------------------
The request is encoded as above, the response is the same as for the The request is encoded as above, the response is the same as for the
N2C request. N2C request.
Implementation Notes:
=====================
This section gives an example of how to configure a web server to
respond to the N2L resolution request. It is not intended to specify
standard behavior, it is provided here merely as a courtesy for
implementors.
First, we assume the presence of a CGI script, n2l.pl, that processes
the provided URN, converting it into a canonical format. It would remove
any "urn:" prefix, decode any %encoded special characters, normalize
case-insensitive parts of the URN to lower case, etc. It would then use
the normalized URN as the key for a search in a database, which we assume
returns the URL as a string. A sample of our implementation of that script
is provided as Appendix B. We will further assume that the n2l.pl script
is in the cgi-bin directory of the web server.
The easiest way to invoke the n2l.pl script in response to N2L requests
is to set up a Redirect directive in the srm.conf file. (This works for
servers based on the original NCSA HTTP daemon, such as Apache.) The
relevant Redirect directives might look like:
Redirect /uri-res/N2L http://urn.acl.lanl.gov/cgi-bin/n2l.pl
Redirect /uri-res/L2N http://urn.acl.lanl.gov/cgi-bin/l2n.pl
Appendix A: The text/uri-list Internet Media Type Appendix A: The text/uri-list Internet Media Type
================================================= =================================================
[This appendix will be augmented or replaced by the registration [This appendix will be augmented or replaced by the registration of the
of the text/uri-list IMT once that registration has been performed]. text/uri-list IMT once that registration has been performed].
Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns, Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns,
L2Ls, result in a list of URIs being returned to the client. The L2Ls, result in a list of URIs being returned to the client. The
text/uri-list Internet Media Type is defined to provide a simple format text/uri-list Internet Media Type is defined to provide a simple
for the automatic processing of such lists of URIs. format for the automatic processing of such lists of URIs.
The format of text/uri-list resources is: The format of text/uri-list resources is:
1) Any lines beginning with the '#' character are comment lines
and are ignored during processing. (Note that '#' is a character
that may appear in URIs, so it only denotes a comment when it is the
first character on a line).
2) The remaining non-comment lines MUST be URIs (URNs or URLs), encoded
according to the URI specification RFC[5]. Each URI shall appear on
one and only one line.
3) As for all text/* formats, lines are terminated with a CR LF pair.
In applications where one URI has been mapped to a list of URIs, such 1) Any lines beginning with the '#' character are comment lines
as in response to the N2Ls request, the first line of the text/uri-list and are ignored during processing. (Note that '#' is a character
response SHOULD be a comment giving the original URI. that may appear in URIs, so it only denotes a comment when it is the
first character on a line).
2) The remaining non-comment lines MUST be URIs (URNs or URLs), encoded
according to the URI specification RFC[6]. Each URI shall appear on
one and only one line.
3) As for all text/* formats, lines are terminated with a CR LF pair,
although clients should be liberal in accepting lines with only
one of those characters.
An example of such a result for the N2L request is shown below in figure 1. In applications where one URI has been mapped to a list of URIs, such
as in response to the N2Ls request, the first line of the text/uri-
list response SHOULD be a comment giving the original URI.
# urn:cid:foo@huh.org An example of such a result for the N2L request is shown below in
http://www.huh.org/cid/foo.html figure 1.
http://www.huh.org/cid/foo.pdf
ftp://ftp.foo.org/cid/foo.txt # urn:cid:foo@huh.org
http://www.huh.org/cid/foo.html
http://www.huh.org/cid/foo.pdf
ftp://ftp.foo.org/cid/foo.txt
Figure 1: Example of the text/uri-list format Figure 1: Example of the text/uri-list format
Appendix B: n2l.pl script Appendix B: n2l.pl script
========================== ==========================
This is a simple perl script for the N2L resolution service. It This is a simple CGI script for the N2L resolution service. It
assumes the presence of a DBM database to store the URN to URL assumes the presence of a DBM database to store the URN to URL
mappings. mappings. This script does not specify standard behavior, it is
provided merely as a courtesy for implementors. In fact, this script
does not process incoming Accept: headers, nor does it generate
status codes. Such behavior should be part of a real script for any
of the resolution services.
#!/bin/perl #!/bin/perl
# N2L - performs urn to url resolution # N2L - performs urn to url resolution
$n2l_File = "...filename for DBM database..."; $n2l_File = "...filename for DBM database...";
$urn = $ENV{'PATH_INFO'} ; $urn = $ENV{'QUERY_STRING'} ;
if(length($urn)<3)
# Sanity check on the URN. Minimum length of a valid URN is
# 7 characters - "urn:", a 1-character Namespace ID, ":", and
# a 1-character namespace-specific string. More elaborate
# sanity checks should be part of a real resolver script.
if(length($urn)<7)
{ {
$error=1; $error=1;
} }
if(!$error) if(!$error)
{ {
$urn =~s/^(\/)(urn:)?(.*)/$3/i; # Convert lexically equivalent versions of a URI into
# Additional canonicalization should be performed here # a canonical version for DB lookups.
$urn =~ s/^urn:([^:]*):(.*)$/sprintf("urn:%s:%s", lc $1, $2)/ie;
dbmopen(%lu,$n2l_File,0444); dbmopen(%lu,$n2l_File,0444);
if($lu{$urn}) if($lu{$urn})
{ {
$url=$lu{$urn}; $url=$lu{$urn};
print STDOUT "Location: $url\n\n"; print STDOUT "Location: $url\n\n";
}else{ }else{
$error=2; $error=2;
} }
dbmclose(%lu); dbmclose(%lu);
} }
if($error) if($error)
{ {
print "Content-Type: text/html \n\n"; print "Content-Type: text/html \n\n";
print "<html>\n"; print "<html>\n";
print "<head><title>URN Resolution: N2L</title></head>\n"; print "<head><title>URN Resolution: N2L</title></head>\n";
print "<BODY>\n"; print "<BODY>\n";
skipping to change at line 348 skipping to change at page 9, line 8
print "<hr><h3>$urn</h3>\n"; print "<hr><h3>$urn</h3>\n";
print "</body>\n"; print "</body>\n";
print "</html>\n"; print "</html>\n";
} }
exit; exit;
References: References:
=========== ===========
[1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource [1] Daniel, Ron and Michael Mealling, RFC 2168, "Resolution of Uniform
Identifiers using the Domain Name System", draft-ietf-urn-naptr-01.txt, Resource Identifiers using the Domain Name System", June 1997.
November, 1996.
[2] RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee, [2] Berners-Lee, T, R. Fielding, H. Frystyk, RFC 1945, "Hypertext
R. Fielding, H. Frystyk, May 1996. Transfer Protocol -- HTTP/1.0", T. Berners-Lee, May 1996.
[3] R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee, [3] Fielding, R., J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", draft-ietf-http-v11-spec-06, RFC 2068, "Hypertext Transfer Protocol -- HTTP/1.1", Jan. 1997.
July 1996.
[4] URN Framework draft - [4] Moats, R., RFC 2141, "URN Syntax", May 1997.
[5] RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax for [5] URN-WG. "URN Resolution Services". Work In Progress.
the Expression of Names and Addresses of Objects on the Network as
used in the World-Wide Web", T. Berners-Lee, June 1994. [6] Berners-Lee, T., RFC 1630, "Universal Resource Identifiers in WWW:
A Unifying Syntax for the Expression of Names and Addresses of
Objects on the Network as used in the World-Wide Web", June 1994.
Security Considerations Security Considerations
======================= =======================
Communications with a resolver may be of a sensitive nature. Some
resolvers will hold information that should only be released to
authorized users. The results from resolvers may be the target of
spoofing, especially once electronic commerce transactions are common
and ther is money to be made by directing users to pirate repositories
rather than repositories which pay royalties to rightsholders. Resolution
requests may be of interest to traffic analysts. The requests may also
be subject to spoofing.
The requests and responses in this draft are amenable to encoding, Communications with a resolver may be of a sensitive nature. Some
signing, and authentication in the manner of any other HTTP traffic. resolvers will hold information that should only be released to
authorized users. The results from resolvers may be the target of
spoofing, especially once electronic commerce transactions are common
and there is money to be made by directing users to pirate
repositories rather than repositories which pay royalties to
rightsholders. Resolution requests may be of interest to traffic
analysts. The requests may also be subject to spoofing.
The requests and responses in this draft are amenable to encoding,
signing, and authentication in the manner of any other HTTP traffic.
Author Contact Information: Author Contact Information:
=========================== ===========================
Ron Daniel Advanced Computing Lab, MS B287
Los Alamos National Laboratory Los Alamos National Laboratory
MS B287 Los Alamos, NM, USA, 87545
Los Alamos, NM, USA, 87545 voice: +1 505 665 0597
voice: +1 505 665 0597 fax: +1 505 665 4939
fax: +1 505 665 4939 email: rdaniel@lanl.gov
email: rdaniel@lanl.gov
This draft expires 21 May, 1997.
Ron Daniel Jr. email: rdaniel@acl.lanl.gov
Advanced Computing Lab voice: (505) 665-0597
MS B-287 TA-3 Bldg. 2011 fax: (505) 665-4939
Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, 87545 obscure_term: "hypernym"
 End of changes. 51 change blocks. 
243 lines changed or deleted 244 lines changed or added

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