draft-ietf-urn-resolution-services-00.txt   draft-ietf-urn-resolution-services-01.txt 
URN Working Group M.Mealling URN Working Group M.Mealling
INTERNET-DRAFT Network Solutions, Inc. INTERNET-DRAFT Network Solutions, Inc.
Expires six months from March 1997 Ron Daniel Jr. Expires six months from June 1997 Ron Daniel Jr.
Intended category: Standards Track Los Alamos National Laboratory Intended category: Standards Track Los Alamos National Laboratory
draft-ietf-urn-resolution-services-01.txt
URN Resolution Services URI Resolution Services
Necessary for URN Resolution
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
skipping to change at line 57 skipping to change at line 59
(but fast). Also, in subsequent conversations it became obvious that, in (but fast). Also, in subsequent conversations it became obvious that, in
most cases, some of the operations were inappropriate or difficult for most cases, some of the operations were inappropriate or difficult for
certain identifiers. For example, ISSNs identify books or magazines that are certain identifiers. For example, ISSNs identify books or magazines that are
serial in nature. An operation to return the resource for an ISSN pointing serial in nature. An operation to return the resource for an ISSN pointing
to "Time" magazine would result in dumping hundreds of thousands of pages of to "Time" magazine would result in dumping hundreds of thousands of pages of
"Time" onto a user's machine. This does not seem like a reasonable thing to "Time" onto a user's machine. This does not seem like a reasonable thing to
do in the normal case. do in the normal case.
The Problem The Problem
The problem, stated simply, was one of a client needing to convey to a The problem, stated simply, is one of a client needing to convey to a
service some idea of the desired operation on a URI that the client is service the desired operation that the client wishes to have done on a given
currently talking about. The problem was also that the server needed to URI. The converse of this problem was that the server needed some way to
convey to a client which network entity could perform which of the convey to a client which services a network entity supported.
operations that were allowed for that particular URI.
This problem requires we specify some well understood set of identifiers This problem requires some well understood set of identifiers that identify
that could identify the operation that a particular network entity either those operations. But it was also realized that an exhaustive set would both
desired or could perform. But it was also realized that an exhaustive set be impossible and not very necessary. Thus, this document will list several
would both be impossible and not very necessary. Thus, while this document operations as well as lay out requirments for specifying new operations.
will list several operations, it will also lay out the requirments for
specifying new operations. Historical Note: Since these services originated with the discussions
surrounding URN resolution, there needs to be a clarification about at which
point in the resoulution process these services reside. The URN resolution
framework [] uses a two step process. The first step is called a Resolution
Discovery Services or RDS. The second part is called a local resolver. The
RDS uses hints to point a client toward a local resolver which actually
answers the questions about the URI. The services described here reside at
the level of the local resolver. The identifiers are used in the RDS to
specify which local resolvers handle which services.
Also, previous versions of this document referred to services where the
arguments were specific types of URIs such as URNs or URLs. These services
were called "N2L", "L2L", etc. Their use has been deprecated here in favor
of the more general URI form.
Design Criteria Design Criteria
The design criteria used to meet these requirements were fairly simple. The The design criteria used to meet these requirements were fairly simple. The
need to simply identify the operation with some token and know its operands need to simply identify the operation with some token and know its operands,
and algorithm was seen as sufficient to meet the requirements. Thus, as with algorithm and errors was seen as sufficient to meet the requirements.
most things simple the simple set of design criteria ended up being: simple,
extensible, generic and short.
As with most design requirements there are several that are at cross
purposes. Thus for anyone adding to this list these design criteria should
be kept in mind and balanced against each other.
2. General Specification 2. General Specification
In order to provide a framework both for the specifications in this document In order to provide a framework both for the specifications in this document
and for new ones to be written by others the following requirments are and for new ones to be written by others, the following requirments are
placed on any documents that seek to specify new operations. placed on any documents that seek to specify new operations.
Any specification of a member of this set of operations MUST contain at Any specification of a member of this set of operations MUST contain at
least the following pieces of information with respect to its operands, its least the following pieces of information with respect to its operands, its
algorithm and its output. algorithm, output and errors.
* 2.1 Operands 2.1 Operands
Must contain the following pieces of information: Must contain the following pieces of information:
o name of the operation
o mnemonic for the operation
o number of operands
o type of each operand
o format of each operand
* 2.2 Algorithm Must either specify the exact algorithm for the operation * name of the operation
or must specify that the algorithm is opaque and defined by the server. * mnemonic for the operation
* number of operands
* type of each operand
* format of each operand
* 2.3 Output Must either specify one of the following: 2.2 Algorithm
o there is no output
o the output is undefined Must either specify the exact algorithm for the operation or that the
o the output itself and its content algorithm is opaque and defined by the server.
o the fact that the output is an object and that objects type and
format. 2.3 Output
Must specify one of the following:
* there is no output
* the output is undefined
* the output itself and its content
* the fact that the output is an object and the object's type and format.
2.4 Error Conditions
Must include all errors that are considered applicable across all
implementations and application environments. Errors that depend on the
system conveying the service are not included. Thus, many of the expected
errors such as syntax errors or service availability are not included in
this document since they are implementation dependent.
2.5 Security Considerations
Must specify any security considerations relating to the serivce provided.
This does NOT include considerations dealing with the protocol used to
convey the service or to those that normally accompany the results of the
service. For example, an I2L service would need to discuss the situation
where someone maliciously inserts an incorrect URL into the resolver but NOT
the case where someone sends personal information across the Internet to the
resource identified by the correct URL.
3. Encoding The Operations 3. Encoding The Operations
To be useful these operations have to be used within some system or To be useful these operations have to be used within some system or
protocol. In many cases these systems and protocols will place restrictions protocol. In many cases these systems and protocols will place restrictions
on which operations make sense and how those that do are syntactically on which operations make sense and how those that do are syntactically
represented. represented.
Also, a given system or protocol will have its own output formats that will Also, a given system or protocol will have its own output formats that will
restrict the output formats of a given operation. Additionally, a given restrict the output formats of a given operation. Additionally, a given
protocol may have better solution for output than the ones given here. For protocol may have better solution for output than the ones given here. For
example, the N2L result may be encoded in a protocol specific manner that example, the I2L result may be encoded in a protocol specific manner that
causes the client to treat it as special. causes the client to treat it as special.
Thus, the requirements on encoding these operations within a given system Thus, the requirements on encoding these operations within a given system
are the following: are the following:
* which subset of the operations are allowed * which subset of the operations are allowed
* how the operator is encoded * how the operator is encoded
* how the operands are encoded * how the operands are encoded
* what the output format is * how the error codes are returned
For those system that can use it, MIME [4] is the suggested output format. For those system that can use it, MIME [4] is the suggested output format.
The operations listed here use the text/uri-list Internet Media Type or IMT The operations listed here use the text/uri-list Internet Media Type or IMT
[4] that is specified in Appendix A. Other system are strongly encouraged to [4] that is specified in Appendix A. Other system are strongly encouraged to
use this IMT. In the case where a system does not use an IMT a justification use this IMT. In the case where a system does not use an IMT a justification
should be given. should be given.
4. The Incomplete Set 4. The Incomplete Set
4.1 N2L (URN to URL) 4.1 I2L (URI to URL)
* name: URN to URL * name: URI to URL
* mnemonic: N2L * mnemonic: I2L
* number of operands: 1 * number of operands: 1
* type of each operand: 1st operand is a URN * type of each operand: 1st operand is a URI
* format of each operand: 1st operand is encoded as a URI * format of each operand: 1st operand is encoded as a URI
* algorithm: opaque * algorithm: opaque
* output: 1 and only one URL encoded in a text/uri-list * output: 1 and only one URL encoded in a text/uri-list
* Errors Conditions:
o No such URI
o No URL to return
* Security Considerations:
This operation is used to map a single URN to a single URL. It is used by o Malicious Redirection
One of the fundamental dangers related to any service such as this
is that a malicious entry in a resolver's database will cause
clients to resolve the URI into the wrong URL. The intent may be
to cause the client to retrieve a resource possibly containing
fradulent or damaging material.
o Denial of Service
By removing the URL that the URI maps to, a malicious intruder may
remove the clients ability to retrieve the resource.
This operation is used to map a single URI to a single URL. It is used by
light weight clients that do not have the ability to select from a list of light weight clients that do not have the ability to select from a list of
URLs or understand a Uniform Resource Characteristic (URC). The algorithm URLs or understand a Uniform Resource Characteristic (URC). The algorithm
for this mapping is dependent on the URN namespace. for this mapping is dependent on the URI scheme.
4.2 N2Ls (URN to URLs) 4.2 I2Ls (URI to URLs)
* name: URN to URLs * name: URI to URLs
* mnemonic: N2LS * mnemonic: I2LS
* number of operands: 1 * number of operands: 1
* type of each operand: 1st operand is a URN * type of each operand: 1st operand is a URI
* format of each operand: 1st operand is encoded as a URI * format of each operand: 1st operand is encoded as a URI
* algorithm: opaque * algorithm: opaque
* output: a list of 0 or more URLs encoded in a text/uri-list * output: a list of 0 or more URLs encoded in a text/uri-list
* Errors:
o No such URI
o No URLs to return
* Security Considerations:
This operation is used to map a single URN to 0 or more URLs. It is used by o Malicious Redirection (see I2L)
o Denial of Service (see I2L)
This operation is used to map a single URI to 0 or more URLs. It is used by
a client that can pick from a list of URLs based on some criteria that is a client that can pick from a list of URLs based on some criteria that is
important to the client. The client should not make any assumptions about important to the client. The client should not make any assumptions about
the order of the URLs returned. the order of the URLs returned.
No matter what the particular media type, the result MUST be a list of the No matter what the particular media type, the result MUST be a list of the
URLs that may be used to obtain an instance of the resource identified by URLs that may be used to obtain an instance of the resource identified by
the URN. All URIs shall be encoded according to the URI specification [6]. the URI. All URIs shall be encoded according to the URI specification [6].
4.3 N2R (URN to Resource) 4.3 I2R (URI to Resource)
* name: URN to Resource * name: URI to Resource
* mnemonic: N2R * mnemonic: I2R
* number of operands: 1 * number of operands: 1
* type of each operand: 1st operand is a URN * type of each operand: 1st operand is a URI
* format of each operand: 1st operand is encoded as a URI * format of each operand: 1st operand is encoded as a URI
* algorithm: opaque * algorithm: opaque
* output: an instance of the resource named by the URN. Encoding is not * output: an instance of the resource named by the URI. Encoding is not
specified. specified.
* Errors:
o No such URI.
o No resource available.
* Security Considerations:
o Malicious Redirection (see I2L)
o Denial of Service (see I2L)
This operation is used to return a single instance of the resource that is This operation is used to return a single instance of the resource that is
named by the URN. The format of the output is dependent on the resource named by the URI. The format of the output is dependent on the resource
itself. itself.
4.4 N2Rs (URN to Resources) 4.4 I2Rs (URI to Resources)
* name: URN to Resources * name: URI to Resources
* mnemonic: N2Rs * mnemonic: I2Rs
* number of operands: 1 * number of operands: 1
* type of each operand: 1st operand is a URN * type of each operand: 1st operand is a URI
* format of each operand: 1st operand is encoded as a URI * format of each operand: 1st operand is encoded as a URI
* algorithm: opaque * algorithm: opaque
* output: 0 or more instances of the resource named by the URN. Encoding * output: 0 or more instances of the resource named by the URI. Encoding
is not specified. is not specified.
* Errors:
o No such URI.
o No resource available.
* Security Considerations:
o Malicious Redirection (see I2L)
o Denial of Service (see I2L)
This operation is used to return multiple instances of a resource, for This operation is used to return multiple instances of a resource, for
example, GIF and JPEG versions of an image. The judgment about the resources example, GIF and JPEG versions of an image. The judgment about the resources
being "the same" resides with the naming authority that issued the URN. being "the same" resides with the naming authority that issued the URI.
The output shall be a MIME multipart/alternative [4] message with the The output shall be a MIME multipart/alternative [4] message with the
alternative versions of the resource in separate body parts. If there is alternative versions of the resource in separate body parts. If there is
only one version of the resource identified by the URN, it MAY be returned only one version of the resource identified by the URN, it MAY be returned
without the multipart/alternative wrapper. without the multipart/alternative wrapper.
4.5 N2C (URN to URC) 4.5 I2C (URI to URC)
* name: URN to URC * name: URI to URC
* mnemonic: N2C * mnemonic: I2C
* number of operands: 1 * number of operands: 1
* type of each operand: 1st operand is a URN * type of each operand: 1st operand is a URI
* format of each operand: 1st operand is encoded as a URI * format of each operand: 1st operand is encoded as a URI
* algorithm: opaque * algorithm: opaque
* output: A Uniform Resource Characteristic. Encoding is not specified. * output: A Uniform Resource Characteristic. Encoding is not specified.
* Errors:
o No such URI.
o URC not available.
* Security Considerations:
o Malicious Redirection (see I2L)
o Denial of Service (see I2L)
URCs (Uniform Resource Characteristics) are descriptions of other resources. URCs (Uniform Resource Characteristics) are descriptions of other resources.
This request allows the client to obtain a description of the resource This request allows the client to obtain a description of the resource
identified by a URN, as opposed to the resource itself or simply the identified by a URI, as opposed to the resource itself or simply the
resources URLs. The description might be a bibliographic citation, a digital resources URLs. The description might be a bibliographic citation, a digital
signature, a revision history, etc. This draft does not specify the content signature, a revision history, etc. This draft does not specify the content
of any response to a URC request. That content is expected to vary from one of any response to a URC request. That content is expected to vary from one
server to another. server to another.
4.6 N2Ns (URN to URNs) 4.6 I2CS (URI to URCs)
* name: URN to URNs * name: URI to URCs
* mnemonic: N2Ns * mnemonic: I2CS
* number of operands: 1 * number of operands: 1
* type of each operand: 1st operand is a URN * type of each operand: 1st operand is a URI
* format of each operand: 1st operand is encoded as a URI * format of each operand: 1st operand is encoded as a URI
* algorithm: opaque * algorithm: opaque
* output: A list of URNs encoded in a text/uri-list IMT. * output: 0 or more Uniform Resource Characteristic. Encoding is not
specified.
* Errors:
o No such URI.
o URCs not available.
* Security Considerations:
While URNs are supposed to identify one and only one resource, that does not o Malicious Redirection (see I2L)
mean that a resource may have one and only one URN. For example, consider a o Denial of Service (see I2L)
resource that has something like "current-weather-map" for one URN and
"weather-map-for-datetime-x" for another URN. The N2Ns service request lets
the client obtain lists of URNs that are believed equivalent at the time of
the request. As the weathermap example shows, some of the equivalences will
be transitory, so the the server should convey the length of time for which
the mapping is valid. The result is a list of all the URNs, known to the
server, which identify the same resource as the input URN. The result shall
be encoded in a text/uri-list IMT.
4.7 L2Ns (URL to URNs) URCs can come in different formats and types. This operation returns 0 or
more URCs that are appropriate for the given URI.
* name: URN to URNs 4.7 I2N (URI to URN)
* mnemonic: N2Ns
* name: URI to URN
* mnemonic: I2N
* number of operands: 1 * number of operands: 1
* type of each operand: 1st operand is a URN * type of each operand: 1st operand is a URN
* format of each operand: 1st operand is encoded as a URI * format of each operand: 1st operand is encoded as a URI
* algorithm: opaque * algorithm: opaque
* output: A list of URNs encoded in a text/uri-list IMT. * output: One URN encoded in a text/uri-list IMT.
* Errors:
o No such URI.
o No URN considered equivalent at this time.
* Security Considerations:
This operation is used to discover the URN associated with a particular URL. o Malicious Redirection (see I2L)
As with all operations dealing with URNs how that URN is mapped is o Denial of Service (see I2L)
completely dependent on the rules specified by the namespace.
4.8 L2Ls (URL to URLs) 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 example, consider a
resource that one organization wishes to name 'foo'. Another organization,
in agreement with the first, wants to call the resource 'bar'. Both
organizations can agree that both names 'name' the same resource and that
the URNs 'foo' and 'bar' are equivalent.
* name: URL to URLs The result a URN, known to the server, which identifies the same resource as
* mnemonic: L2Ls the input URN. The result shall be encoded in a text/uri-list IMT.
* number of operands: 1
* type of each operand: 1st operand is a URL
* format of each operand: 1st operand is encoded as a URI
* algorithm: opaque
* output: A list of URLs encoded in a text/uri-list IMT.
This operation is used to discover URLs that are considered equal to each Extreme care should be taken with this service as it toys with the idea of
other. As with the N2N operation "equality" is defined by the server and is equality with respect to URNs. As mentioned in several URN documents the
opaque to the client. idea of equality is very domain specific. For example, a URN pointing to a
weather map for a particular day and a URN pointing to the the map as it
changes from day to day would NOT by returned in this example because they
point to do different resources. Some other concept of equality is at work.
This service instead deals with resources that have two different names
where the binding between the names and resources is permanent.
4.9 L2C (URL to URC): 4.8 I2Ns (URI to URNs)
* name: URL to URC * name: URI to URNs
* mnemonic: L2C * mnemonic: I2NS
* number of operands: 1 * number of operands: 1
* type of each operand: 1st operand is a URL * type of each operand: 1st operand is a URI
* format of each operand: 1st operand is encoded as a URI * format of each operand: 1st operand is encoded as a URI
* algorithm: opaque * algorithm: opaque
* output: A URC. * output: A list of URNs encoded in a text/uri-list IMT.
* Errors:
o No such URI.
o No URNs considered equivalent at this time.
* Security Considerations:
This operation is used to retrieve the URC for a given URL. As with most o Malicious Redirection (see I2L)
other URI mappings the mapping function is opaque. As with any other o Denial of Service (see I2L)
operation that returns a URC, the output format is unspecified.
4.10 I2I (URI to URI): This operation simply returns 0 or more URNs following the same criteria and
cautions as the I2N operation.
4.9 I2I (URI to URI):
* name: URI to URI * name: URI to URI
* mnemonic: I2I * mnemonic: I2I
* number of operands: 1 * number of operands: 1
* type of each operand: 1st operand is a URL * type of each operand: 1st operand is a URL
* format of each operand: 1st operand is encoded as a URI * format of each operand: 1st operand is encoded as a URI
* algorithm: opaque * algorithm: opaque
* output: A URI. * output: A URI.
* Errors:
o No such URI.
o No URIs considered equivalent at this time.
* Security Considerations:
o Malicious Redirection (see I2L)
o Denial of Service (see I2L)
This operation is used to map any arbitrary URI to any other arbitrary URI. This operation is used to map any arbitrary URI to any other arbitrary URI.
No other assertions are made about whether or not the URI exhibits No other assertions are made about whether or not the URI exhibits
characteristics of URNs or URLs. characteristics of URNs or URLs.
4.11 N2I (URI to URI): 4.10 I=I (Is URI equal to URI):
* name: URN to URI
* mnemonic: N2I
* number of operands: 1
* type of each operand: 1st operand is a URL
* format of each operand: 1st operand is encoded as a URI
* algorithm: opaque
* output: A URI.
This operation is used to map a URN to any other arbitary URI. No other
assertions are made about whether or not the URI exhibits characteristics of
URNs or URLs.
4.11 I=I (Is URI equal to URI):
* name: URI = URI * name: URI = URI
* mnemonic: I=I * mnemonic: I=I
* number of operands: 2 * number of operands: 2
* type of each operand: Both operands are URIs * type of each operand: Both operands are URIs
* format of each operand: both operands are encoded as a URIs * format of each operand: both operands are encoded as a URIs
* algorithm: opaque * algorithm: opaque
* output: TRUE or FALSE * output: TRUE or FALSE
* Errors:
o No such URI.
o No URIs considered equivalent at this time.
* Security Considerations:
o Malicious Redirection (see I2L)
o Denial of Service (see I2L)
This operation is used to determine whether two given URIs are considered to This operation is used to determine whether two given URIs are considered to
be equal by the server being asked the question. The algorithm used to be equal by the server being asked the question. The algorithm used to
determine equality is opaque. No assertions are made about whether or not determine equality is opaque. No assertions are made about whether or not
the URIs exhibits characteristics of URNs or URLs. the URIs exhibits characteristics of URNs or URLs.
6. The text/uri-list Internet Media Type 6. The text/uri-list Internet Media Type
[This section will be augmented or replaced by the registration of [This section will be augmented or replaced by the registration of
the text/uri-list IMT once that registration has been performed]. the text/uri-list IMT once that registration has been performed].
Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns, L2Ls, Several of the resolution service requests, such as I2Ls, I2Ns, result in a
result in a list of URIs being returned to the client. The text/uri-list list of URIs being returned to the client. The text/uri-list Internet Media
Internet Media Type is defined to provide a simple format for the automatic Type is defined to provide a simple format for the automatic processing of
processing of such lists of URIs. 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 1. Any lines beginning with the '#' character are comment lines and are
ignored during processing. (Note that '#' is a character that may ignored during processing. (Note that '#' is a character that may
appear in URIs, so it only denotes a comment when it is the first appear in URIs, so it only denotes a comment when it is the first
character on a line). character on a line).
2. The remaining non-comment lines MUST be URIs (URNs or URLs), encoded 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 according to the URI specification RFC[6]. Each URI shall appear on one
and only one line. and only one line.
3. As for all text/* formats, lines are terminated with a CR LF pair, 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 although clients should be liberal in accepting lines with only one of
those characters. those characters.
4. The order of the URIs given MUST be preserved upon retransmission. The 4. The order of the URIs given MUST be preserved upon retransmission. The
client should not make any inferences about what the order of the client should not make any inferences about what the order of the
returned list means. returned list means.
In applications where one URI has been mapped to a list of URIs, such as in 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 response to the I2Ls request, the first line of the text/uri-list response
SHOULD be a comment giving the original URI. SHOULD be a comment giving the original URI.
An example of such a result for the N2L request is shown below in figure 1. An example of such a result for the I2L request is shown below in figure 1.
-------------------------------------------------- --------------------------------------------------
# urn:cid:foo@huh.org # urn:cid:foo@huh.org
http://www.huh.org/cid/foo.html http://www.huh.org/cid/foo.html
http://www.huh.org/cid/foo.pdf http://www.huh.org/cid/foo.pdf
ftp://ftp.foo.org/cid/foo.txt 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
-------------------------------------------------- --------------------------------------------------
7. References 7. References
[1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource [1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource
Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt, Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt,
February, 1997. February, 1997.
[2] R. Moats, "URN Syntax", draft-ietf-urn-syntax-02, Jan. 1997. [2] R. Moats, "URN Syntax", RFC2141, Jan. 1997.
[3] RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax for [3] RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax for
the Expression of Names and Addresses of Objects on the Network as the Expression of Names and Addresses of Objects on the Network as
used in the World-Wide Web", T. Berners-Lee, June 1994. used in the World-Wide Web", T. Berners-Lee, June 1994.
[4] RFC 1521, "MIME (Multipurpose Internet Mail Extensions) Part One: [4] RFC 1521, "MIME (Multipurpose Internet Mail Extensions) Part One:
Mechanisms for Specifying and Describing the Format of Internet Message Mechanisms for Specifying and Describing the Format of Internet Message
Bodies", Borenstein, N. and and N. Freed, Bellcore, Innosoft, Bodies", Borenstein, N. and and N. Freed, Bellcore, Innosoft,
September 1993. September 1993.
 End of changes. 68 change blocks. 
132 lines changed or deleted 219 lines changed or added

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