| TOC |
|
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 December 30, 2004.
Copyright (C) The Internet Society (2004).
The purpose of this RFC is to focus discussion on intellectual property problems in the Internet.
This document introduces and defines scope modifiers to be used in intellectual property declarations. These modifiers abstract the ownership behavior of resources available in interoperable environments, such as the Internet.
1.
Introduction
1.1
Intended audience
1.2
Definitions
1.3
Requirement notation
2.
Semantics of interoperability
2.1
An analogy: the logic of classes
2.2
Categories of operations
2.3
Reciprocity and equivalence
3.
Definition of scope modifiers
3.1
PRIVATE modifier
3.2
PROTECTED modifier
3.3
INTERNET modifier
3.4
PUBLIC modifier
3.5
Scope inheritance
4.
Syntax of ownership declarations
4.1
Formal declaration
4.2
Property line
4.3
Attribution line
4.4
License line
4.5
Long names and short names of modifiers
5.
Scope modifiers implementation
5.1
Handwritten implementation: the default modifier
5.2
HTML implementation: the SCOPE tag
5.3
Dublin Core implementation
5.4
Using licenses
6.
Security Considerations
7.
References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
This document defines four scope modifiers to be used in intellectual property declarations of resources available in interoperable environments, such as Internet. They help to abstract the ownership behavior of these resources.
We proceed in three steps. We characterize the semantics of the operations applicable on resources, based on the pair (URI, ownership). Then we determine the modifiers that control the interoperability of resources. Finally we describe the general syntax of the ownership declarations that use these modifiers. An fourth chapter will introduce various implementations of the described syntax.
Four modifiers are defined. The PUBLIC, PROTECTED and PRIVATE modifiers are transpositions of the class programming equivalents. A fourth modifier -- the INTERNET modifier -- operates like an all-country exclusion: it allows the transformation, but does not allow the reproduction, of a private resource exhibited in interoperable environments, such as Internet.
As an example, the following declaration illustrates a typical usage of the PUBLIC and PRIVATE modifiers. This declaration asserts that OwnerB's private resource (the client resource) is a derivative version of OwnerA's public resource (the server resource).
Private(C) 2004, OwnerB (http://www.client.com)
& Public(C) 2002-2004, OwnerA (http://www.server.com)
All rights reserved.
No special knowledge is expected from readers. However, some concepts have a background and rely on a vocabulary that is more familiar to specialized readers:
INTELLECTUAL PROPERTY BASED OBJECT (IP OBJECT) is an instance of a work, as defined by Berne Convention (Art. 2), and the laws of the countries of the Berne Union [BERNE]World Intellectual Property Organization, WIPO., Berne Convention for the Protection of Literary and Artistic Works, Paris Act of July 24, 1971, as amended on September 28, 1979..
RESOURCE is an IP Object defined unambiguously in an interoperable environment by two properties: its URI and an ownership declaration. More strictly, a resource is an interface defined by the pair (URI, ownership) of an IP object made available in an interoperable universe
OWNERSHIP is a resource property, defined by the Berne Convention (Art. 5), and the laws of the countries of the Berne Union [BERNE]World Intellectual Property Organization, WIPO., Berne Convention for the Protection of Literary and Artistic Works, Paris Act of July 24, 1971, as amended on September 28, 1979..
URI is a resource property, the Universal Resource Identifier of an IP object, defined in [RFC2396]Berners-Lee, T., Fielding, R., Irvine, U. and L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, August 1998..
SCOPE (OF OWNERSHIP), as used in this document, determines the resource behavior in regard of specific operations: exhibition (instantiation), execution (performance), reproduction (copy) and transformation (derivation). Brackets only denote synonyms for operations defined in this document.
SCOPE MODIFIER, is a conventional token attached to an ownership declaration,
used to alter the behavior of the resource in an interoperable environment.
The aim of this document is to define and to describe such scope modifiers.
SERVER and CLIENT RESOURCES. A server resource refers to the original
resource, which has been reproduced or transformed, to create a client resource.
A client resource is the resulting reproduction or transformation of a server resource.
A version is also a client resource, which designates specifically the result of the
transformation of the server resource.
INTEROPERABILITY is defined following the IEEE Standard Computer Dictionary: "the ability of two or more systems or components ("resources") to exchange information and to use the information that has been exchanged" [IEEE 90]Institute of Electrical and Electronics Engineers, IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY, 1990..
INTERNET, is an interoperable environment of resources.
In this document, INTERNET is also the conventional name of a scope modifier.
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]S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, March 1997..
| TOC |
This first chapter will analyze the semantic of the operations applicable on resources. Next chapter defines the scope modifiers that alter the behavior of resources; and the last chapter describes the general syntax of the ownership declarations.
As a starting point, we present an analogy between Resources declarations and Class declarations used in class programming languages. This analogy is not required to fully understand this document.
Given the "(c) year, author" expression, the legal mention to the Country is implicit. Indeed, we could write:
"France (c) 2004, I.Robredo"
In our example, "Country" is a virtual base class, from which we derive a special rightsholder class: the class "I.Robredo". Each instance of this Rightsholder class is a concrete IP Object, identified unambiguously by an URI. For example, the URI of a manuscript or a song is the title, the author's name and the date.
The declaration above may be read as follow:
"France (c) 2004, I.Robredo"
Is an ownership declaration of an IP object, where:
France is the name of the virtual, country base class.
Optional. By default, the author's country.
I.Robredo is the name of the rightsholder class,
derived from the country class
(usually the Author's name, but can be any
entity).
... 2004 is an instance of the I.Robredo class. The
IP object itself is defined by the 2004 version
(along with the title, the author's name, ...).
An ownership declaration can be used when the rightsholder wants to make available an IP Object in an interoperable environment, under specific conditions of ownership. This object is called a resource. Two properties will determine the resource behavior in the interoperable environment: its URI and the ownership declaration.
Before being available, the resource is unknown and the ownership declaration is not even required. This declaration is really required to allow some interoperations on the resource. In other words, the ownership declaration is used to determine or to alter the interoperability of the resource.
In Class programming languages, special modifiers attached to Class declarations are used to determine the results of operations on the classes and on the object instances. In other words, these modifiers can define the semantics of the relations between classes or between objects. This document shows that similar conventions can be applied to the resources exhibited in interoperable environments, such as Internet.
A resource is defined by a couple of properties: its URI and its ownership declaration.
Some relations may be identified between these properties:
All these relations are contained in the answers to the following two questions. For any operation:
Four operations are defined as follows (alias names are parenthesized):
EXHIBITION (Instantiation) The Owner instantiates an IP Object
by defining its URI and ownership properties.
Exhibition of the resource is always accomplished by
the rightsholder (for example: the author).
EXECUTION (Performance) There is no URI creation. A volatile
instance of the IP Object is performed.
Whether the performer is the rightsholder or another
different person, the ownership of this volatile
resource remains the same, and belongs to the original
rightsholder.
REPRODUCTION (Copy) A new, persistent URI is created, and the
resource exhibited under this new URI is called a
"client resource".
Whether the underlying object under each URI is the
same object or a duplicate object, the ownership of
both server and client resources remains the same, and
belongs to the original rightsholder.
TRANSFORMATION (Derivation) A new, persistent client resource
is created, with separate properties (URI, ownership).
This client resource is called a "version" of the
original server resource.
Even whether the rightsholder of both server and
client resources is the same person, the ownership
attached to the version resource is different from
the ownership of the original resource.
The ownership declaration on the version is asserted
by the exhibitor of the resource.
The following table resumes the above relations between URI and ownership:
Operation | Question 1: Question 2:
| Is there a 2nd In case of URI creation, is
| URI creation? there a separate ownership?
----------------|--------------------------------------------
EXHIBITION | No -
EXECUTION | No -
|
REPRODUCTION | Yes No
TRANSFORMATION | Yes Yes
----------------|--------------------------------------------
This section is not required to fully understand this document, and it refers explicitly to the 5 first articles of the Berne Convention. [BERNE]World Intellectual Property Organization, WIPO., Berne Convention for the Protection of Literary and Artistic Works, Paris Act of July 24, 1971, as amended on September 28, 1979..
The exhibition and execution operations require some explanations.
Otherness is the key concept to differentiate exhibition and execution: the person who executes a resource is not required to be the same person who exhibits it. The exhibitor and the performer of the work can be different persons. For example, given a computer software, we say that only the rightsholder can exhibit the source code, while any (authorized) person can execute the object code.
Otherness is the basis of two complementary principles: the reciprocity in protection given by countries (Berne-A3 and A5) and the equivalence in ownership of transformed resources (Berne A2.3). Both principles are governed by an explicit non-damaging restriction: client ownership cannot make prejudice to server ownership.
We say that this non-damaging rule governs the "inheritance" of resource behaviors.
Ideally, allowing the transformation of a resource does not imply that the derivative resource can be transformed as well. There is a separate ownership between both server and client resources, in case of transformation. However, the non-damaging rule still works here, either explicitly, or implicitly:
The non-damaging rule can enforce the inheritance. The same rule can also alter the default reciprocity and equivalence behaviors. In this case, the way to alter the default inheritance mechanism is using scope modifiers.
| TOC |
In the previous chapter, we analyzed the semantics of inter-operations on resources defined by the pair (URI, ownership). In this chapter, we define the modifiers that are used to alter the resource behaviors. The general syntax of the ownership declarations will be described in the next chapter.
There is a formal relationship between the URI property and the EXECUTION or REPRODUCTION operations. A second URI is always attached to all reproductions of the resource. In other words, the difference between a simple execution and a true reproduction raises when a new URI is defined for the copied resource.
Conversely, there is a semantic relationship between the ownership property and the EXHIBITION and TRANSFORMATION operations. An exhibited resource is always managed by its rightsholder. However, a true transformation implies a second user, which in turn, has a complete ownership on the version produced.
The following summarizes REPRODUCTION and TRANSFORMATION operations, and how they determines a new URI creation, or a separate ownership, or both:
Operation | Separate Separate
| URI? ownership?
------------------|--------------------------------
REPRODUCTION | Yes No
TRANSFORMATION | Yes Yes
------------------|--------------------------------
Then we create the truth table of REPRODUCTION and TRANSFORMATION capabilities to identify each entry with four scope modifiers:
REPRODUCTION TRANSFORMATION | SCOPE is
------------------------------------------------
No No | PRIVATE
Yes No | PROTECTED
No Yes | INTERNET
Yes Yes | PUBLIC
------------------------------------------------
The following table is the same than above, but it
is possible to read it out in a more natural way.
The symbols '-' and '+' mean
that the operation is denied, or allowed,
respectively. The symbol '-' can be read like 'not',
while the symbol '+' correspond to a silence (a consent).
The resource is | When the resource can be
------------------------------------------------
PRIVATE | -REPRODUCED and -TRANSFORMED
PROTECTED | +REPRODUCED but -TRANSFORMED
INTERNET | -REPRODUCED but +TRANSFORMED
PUBLIC | +REPRODUCED and +TRANSFORMED
------------------------------------------------
This truth table shows clearly that the space allocated to the INTERNET modifier is a logical imperative of the semantics of interoperability.
The PRIVATE modifier means that no secondary URI, and no separate ownership are allowed for the resource. No reproduction, and no transformation are allowed.
By default, the exhibition and the execution of a PRIVATE resource
is restricted to the rightsholder.
The PROTECTED modifier means that the reproduction of the resource is allowed under a client URI, but no separate ownership is granted. Reproduction is allowed, but transformation is forbidden.
The client resource inherits the same scope than server. By default, it is possible to make news reproductions of the client resource.
A protected resource is typically managed with a license. For example, a license can be used in a collective project that encourages the reproduction of the work. A protected license can even create a "mixed scope", by allowing some transformations capabilities to resources.
The INTERNET modifier means that the transformation of the resource is allowed, but its reproduction is forbidden.
The INTERNET modifier can be defined as a "country excluder". This exclusion rationale highlights the fact that the server resource appears just like a private resource under the laws of all countries. In other words, the client version cannot be reproduced in any country, and its ownership is only recognized by the original rightsholder.
However, a separate ownership exists and the client version inherits the same scope than the server resource. For example, it is not possible (even to the original rightsholder) to reproduce the transformed version in any country.
Traditional ownership is built upon country reciprocity. The Internet scope shows that individuals can still enforce the resource ownership under a country exclusion. Otherness is also matter of individual, rather than of the countries.
To summarize, the Internet scope has three characteristics:
The Internet resource can also be managed by a license. For example, to authorize the reproduction of a specific version, based on the polling of readers.
Without the INTERNET scope modifier, it would be impossible to understand the widest part of the behavior of resources in interoperable environments, such as Internet.
The PUBLIC means that the reproduction and transformation of the resource is allowed under a client URI, and a separate ownership is recognized to derivative versions.
The client resource inherits the same scope than server. By default, the client resource is public.
PUBLIC scope must not be confused with "public domain". The rightsholder of the public resource keeps the full control on the resource.
The rule of scope inheritance is described in the following table. More advanced explanations on inheritance can be read in previous section (see "Reciprocity and Equivalence").
Given 2 resources, server and client, the scope modifier of the client declaration SHALL be either the same or a more restrictive modifier.
Server | Client resource MAY be: resource is | Private Protected Internet Public ---------------------------------------------------- PRIVATE | Yes -- -- -- PROTECTED | -- Yes -- -- ----------------------------------------------------- INTERNET | Yes -- Yes -- ----------------------------------------------------- PUBLIC | Yes Yes Yes Yes -----------------------------------------------------
Notes:
This document does not define precedence rules for scope modifiers.
| TOC |
In previous chapters, we analyzed the semantics of interoperability, then we defined four scope modifiers for ownership declarations. This chapter describes the RECOMMENDED syntax of such declarations.
The formal declaration is a multiline text. Server and client resources declarations share the same declaration syntax.
The syntax is based on three possible line types.
A server declaration contains a Property line and optionally, a License line:
[modifier](C) [date][owner] (Property line) [standard assertion or license link] (License line)
A client declaration contains the same lines than the server declaration, plus one or more attribution lines:
[modifier](C) [date][owner] (Property line) & [modifier](C) [date][owner] (Attribution line) [standard assertion or license link] (License line)
Here is an example of an Internet client declaration:
Internet(C) 2004, ClientOwner (client-owner@clientsite.com)
& Internet(C) 2004, ServerOwner (server-owner@serversite.com)
All rights reserved in all countries.
Property line MUST appear for all modifiers. The Property line is composed of:
Modifier Scope
-------------------------------------
(none) PRIVATE
[Private](C) PRIVATE
Protected(C) PROTECTED
Public(C) PUBLIC
Internet(C) INTERNET
-------------------------------------
In a compliant declaration, the (C) symbol MUST follow the scope modifier. The (C) symbol MUST appears even if no modifier is used or Country Law does not require it.
Two examples:
Internet(C) 2004, OwnerName (owner-x@somesite.com)
Public(C) 2002-2004, OwnerName (owner-x@somesite.com)
The Attribution line SHALL be used in an ownership declaration when the resource is a transformed version of the original or when multiple rightsholders share different rights on it.
The use of an AMPERSAND sign ('&') in front of Attribution line is RECOMMENDED.
The syntax of Attribution line is otherwise similar to the Property line. For example:
Internet(C) 2004, OwnerC (http://www.clientC.com)
& Internet(C) 2002-2004, OwnerB (http://www.client_server.com)
& Public(C) 2002, OwnerA (http://www.server.org)
When multiple server resources have been used, or because there are multiple rightsholders, the ownership declaration may contain multiple attribution lines. For example:
[modifier](C) [date][Local Rightsholder for the translation] & [modifier](C) [date][Worldwide Rightsholder for all languages] & [modifier](C) [date][Author who sold the original rights] [standard assertion or license link]
License line is OPTIONAL and can be used with any modifier to override the default behavior of the resource.
The license line can be multiline and MUST close the ownership declaration, after the Property line and the Attribution line(s).
The license line is a free text that usually relies on conventional expressions, as used in the country of the protected resource.
Private(C) 2004, Owner (http://www.clienttranslation.com)
All rights reserved
Here is another sample in French.
Internet(C) 2004, NomDuClient (http://www.client.fr)
& Internet(C) 2002-2004, NomDuServeur (http://www.serveur.ca)
Reproduction interdite
The license line can refer to a license identified by an external URI.
Internet(C) 2004, OwnerX (owner-x@somesite.com)
LGTv1r4: http://www.in3activa.org
Scope modifiers are chosen from a finite token list, with four elements:
Private, Protected, Internet, Public.
All uppercase or lowercase variations are allowed and these variations
do not modify the modifier semantics .
This document does not define localized names for these tokens. However, it defines short equivalents, as in the following table:
Long name Short name
-------------------------------------
Private(C) pri(c)
Protected(C) pro(c)
Public(C) pub(c)
Internet(C) int(c)
-------------------------------------
Here is a compliant handwritten implementation using short names:
Int(C) 2004, RightsHolder ...
Note: usage of short equivalents is reserved to the handwritten implementation of the syntax. Metalanguage descriptions (such HTML or Dublin Core) MUST use long names for modifiers.
| TOC |
After we analyzed the semantics of the interoperability of resources based on the pair (URI, ownership), we determined four scope modifiers, and proposed a recommended syntax to use the ownership declarations.
As a conclusion to this specification, this chapter describes three compliant implementations of the scope modifiers.
The handwritten implementation matches the full syntax specification of scope modifiers. The handwritten implementation also allows the usage of short names of modifiers. For a complete handwritten implementation, see the previous chapter.
To follow the common usage in the countries of Berne Union, a compliant handwritten implementation SHALL consider the PRIVATE modifier as the default modifier.
The following declaration :
(C) 2004, RightsHolder ..
will be interpreted as:
Private(C) 2004, RightsHolder ...
Scope modifiers are well suited for automated processing by robots, and for dissemination of resources in the Internet. Among multiple possibilities, we define the HTML implementation [HTML40]W3C, Hypertext Markup Language 4.0 Specification, April 1998., because it can be easily adapter to other metalanguage specifications (XML, RDF, etc).
The RECOMMENDED implementation of this framework with the HTML 4.0 language MUST include:
The following example describes a protected HTML resource:
<html>
<head>
...
<meta name = "scope"
content = "internet" >
...
</head>
<body><pre>
...
</pre></body>
</html>
The content attribute defines the default scope of the resource. HTML body tags that define specific content boundaries may override this default scope
The following sample defines a Public scope portion, located inside the default Internet scope of the resource. Both syntax are allowed and MUST be recognized by automatic processing:
<scope content="public"> ... <scope>
or
<scope public> ... <scope>
The Dublin Core specification offers a richer layout for scope modifiers. This section describes the addition of the "scope" modifier to the Dublin core specification [RFC2731]Kunze, J., Encoding Dublin Core Metadata in HTML, RFC 2731, December 1999..
The addition is based on a new SCOPE element, to be used along with the already defined Rights Element:
<html>
<head>
<title>Le ravissement d'Europe</title>
<link rel = "schema.DC"
href = "http://purl.org/DC/elements/1.0/">
<meta name = "DC.Title"
content = "Charte in3ActivA de traducteurs...">
<meta name = "DC.Creator"
content = "Robredo, I">
<meta name = "DC.Type"
content = "Contrat">
<meta name = "DC.Date"
content = "2004">
<meta name = "DC.Format"
content = "text/html">
<meta name = "DC.Language"
content = "fr">
<meta name = "DC.Rights"
lang = "fr"
content= "http://www.in3activa.org/doc/fr/LGT-FR.html">
<meta name = "DC.Scope"
content= "Internet">
</head>
<body><pre>
...
</pre></body>
</html>
This Dublin Core example would be equivalent to the following handwritten declaration (possibly inserted at the end of the resource):
internet(C) 2004, I.Robredo
http://www.in3activa.org/doc/fr/LGT-FR.html
The scope modifiers provide a powerful, although generic, framework for resources. To enlarge or restrict the scope of the resource ownership, the rightsholders may define a license and override the default behavior of scope modifiers.
For example, a license may override the protected scope of software resource, and it can authorize the resource transformation under specifics conditions.
Conversely, the license of an Internet resource can be provided to authorize the reproduction in some countries, such as the licensee's country. For example, the license attached to an Internet resource may allow a book reproduction to be sold in specific countries, without prejudice to the original ownership.
(c) 2004, I.Maturana for the Spanish version
&Internet (C) 1999-2004, I.Robredo
http://www.in3activa.org/doc/es/LGT-ES.html
The framework provided by scope modifiers introduces the opportunity for rightsholders to create and develop powerful licenses schemas, based on the analysis and the simulation of resource behaviors, in interoperable environments, including the Internet.
| TOC |
None.
| TOC |
| [BERNE] | World Intellectual Property Organization, WIPO., "Berne Convention for the Protection of Literary and Artistic Works", Paris Act of July 24, 1971, as amended on September 28, 1979. |
| [CPPREF] | Ellis, M. and B. Stroustrup, "The annotated C++ Reference Manual", 1990. |
| [HTML40] | W3C, "Hypertext Markup Language 4.0 Specification", April 1998. |
| [IEEE 90] | Institute of Electrical and Electronics Engineers, "IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY", 1990. |
| [LGT] | Maturana, I. and I. Robredo, "General license of translation", 1990-2004. |
| [RDF] | W3C, "Resource Description Framework Model and Syntax Specification", February 1999. |
| [RFC2119] | S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", March 1997. |
| [RFC2396] | Berners-Lee, T., Fielding, R., Irvine, U. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", August 1998. |
| [RFC2413] | Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin Core Metadata for Resource Discovery, RFC 2413", September 1998. |
| [RFC2731] | Kunze, J., "Encoding Dublin Core Metadata in HTML, RFC 2731", December 1999. |
| [XML] | W3C, "Extensible Markup Language (XML)", 2004. |
| TOC |
| I.Maturana | |
| in3activa | |
| Aptdo 15.117 | |
| Madrid, Spain | |
| I.Robredo | |
| in3activa | |
| Ziburu, France |
| TOC |
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.
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 (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.
Funding for the RFC Editor function is currently provided by the Internet Society.