Network Working Group I. Maturana Internet-Draft I. Robredo Expires: December 30, 2004 in3activa July 2004 Scope Modifiers in Intellectual Property Declarations draft-maturana-ipscope-02.txt 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 December 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). Abstract 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. Maturana & Robredo Expires December 30, 2004 [Page 1] Internet-Draft Internet(C) July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Intended audience . . . . . . . . . . . . . . . . . . . . 3 1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Requirement notation . . . . . . . . . . . . . . . . . . . 4 2. Semantics of interoperability . . . . . . . . . . . . . . . . 5 2.1 An analogy: the logic of classes . . . . . . . . . . . . . 5 2.2 Categories of operations . . . . . . . . . . . . . . . . . 6 2.3 Reciprocity and equivalence . . . . . . . . . . . . . . . 8 3. Definition of scope modifiers . . . . . . . . . . . . . . . . 10 3.1 PRIVATE modifier . . . . . . . . . . . . . . . . . . . . . 11 3.2 PROTECTED modifier . . . . . . . . . . . . . . . . . . . . 11 3.3 INTERNET modifier . . . . . . . . . . . . . . . . . . . . 11 3.4 PUBLIC modifier . . . . . . . . . . . . . . . . . . . . . 12 3.5 Scope inheritance . . . . . . . . . . . . . . . . . . . . 13 4. Syntax of ownership declarations . . . . . . . . . . . . . . . 14 4.1 Formal declaration . . . . . . . . . . . . . . . . . . . . 14 4.2 Property line . . . . . . . . . . . . . . . . . . . . . . 15 4.3 Attribution line . . . . . . . . . . . . . . . . . . . . . 15 4.4 License line . . . . . . . . . . . . . . . . . . . . . . . 16 4.5 Long names and short names of modifiers . . . . . . . . . 17 5. Scope modifiers implementation . . . . . . . . . . . . . . . . 18 5.1 Handwritten implementation: the default modifier . . . . . 18 5.2 HTML implementation: the SCOPE tag . . . . . . . . . . . . 18 5.3 Dublin Core implementation . . . . . . . . . . . . . . . . 19 5.4 Using licenses . . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . 24 Maturana & Robredo Expires December 30, 2004 [Page 2] Internet-Draft Internet(C) July 2004 1. Introduction 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. 1.1 Intended audience 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: o Intellectual property rights, as defined for protected works by the Berne Convention [BERNE]. o Class modifiers such as Public, Private and Protected, as defined in Class programming languages; [CPPREF] 1.2 Definitions INTELLECTUAL PROPERTY BASED OBJECT (IP OBJECT) is an instance of a work, as defined by Berne Convention (Art. 2), and the laws of the Maturana & Robredo Expires December 30, 2004 [Page 3] Internet-Draft Internet(C) July 2004 countries of the Berne Union [BERNE]. 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]. URI is a resource property, the Universal Resource Identifier of an IP object, defined in [RFC2396]. 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]. INTERNET, is an interoperable environment of resources. In this document, INTERNET is also the conventional name of a scope modifier. 1.3 Requirement 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]. Maturana & Robredo Expires December 30, 2004 [Page 4] Internet-Draft Internet(C) July 2004 2. Semantics of interoperability 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. 2.1 An analogy: the logic of classes 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. Maturana & Robredo Expires December 30, 2004 [Page 5] Internet-Draft Internet(C) July 2004 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. 2.2 Categories of operations A resource is defined by a couple of properties: its URI and its ownership declaration. Some relations may be identified between these properties: o The same URI cannot point resources from different rightsholders. o Two URIs may point to either the same or duplicated resources. o Different rightsholders cannot attach the same URI to their ownership declaration. All these relations are contained in the answers to the following two questions. For any operation: o Will the operation on a resource create a second URI? o In case of URI creation, is there a separate ownership on the client resource ? Four operations are defined as follows (alias names are parenthesized): Maturana & Robredo Expires December 30, 2004 [Page 6] Internet-Draft Internet(C) July 2004 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 ----------------|-------------------------------------------- Maturana & Robredo Expires December 30, 2004 [Page 7] Internet-Draft Internet(C) July 2004 2.3 Reciprocity and equivalence This section is not required to fully understand this document, and it refers explicitly to the 5 first articles of the Berne Convention. [BERNE]. The exhibition and execution operations require some explanations. o Exhibition is a pragmatic equivalent of the verb "creation", which is not defined by itself, but it is implied by Berne-A2.2, as a work fixed in a form. Whether a work is published or not (Berne-A3,1a), it can be exhibited. The word exhibition is a shorthand to describe the instantiation of a resource under 2 coordinates: its URI and its ownership declaration. When an IP object is instantiated under the pair (URI, ownership declaration), this object becomes accessible and it is possible to inter-operate with it. o Execution is a synonym for performance, which is not defined by itself, but it is implied by Berne-A3,3: the performance of a protected work shall not constitute publication. We choose the word "execution" because it is typically used to describe software execution, but it could be used for the recitation of a poetry, or to describe the application of this document on Internet resources as well. 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. o Any reproduction or transformation of an exhibited work can be exhibited as well (or it cannot be reproduced nor transformed). o If the server resource can be executed, any client resource (either transformed or reproduced) can be executed as well. o Allowing the reproduction of a server resource under a different URI will imply that the duplicate resource can be reproduced as well. Ideally, allowing the transformation of a resource does not imply Maturana & Robredo Expires December 30, 2004 [Page 8] Internet-Draft Internet(C) July 2004 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: o The non-damaging rule can be used to explicitly enforce the inheritance: transformation of the server resource will be granted only if the client resource will also allow the transformation. Otherwise, transformation of the server resource is forbidden. o Without an agreement, the non-damaging rule still works like a safeguard of both reciprocity and equivalence principles. Everything allowed for a server resource is expected to be allowed for client resources, while anything excluded for the server will be always excluded for clients. For example, translation is allowed for a book, but some languages are excluded. A translator cannot allow re-translation to the already excluded languages; and trying to prevent the re-translation to even more languages is unenforceable. 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. Maturana & Robredo Expires December 30, 2004 [Page 9] Internet-Draft Internet(C) July 2004 3. Definition of scope modifiers 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. Maturana & Robredo Expires December 30, 2004 [Page 10] Internet-Draft Internet(C) July 2004 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. 3.1 PRIVATE modifier 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. 3.2 PROTECTED modifier 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. 3.3 INTERNET modifier 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 Maturana & Robredo Expires December 30, 2004 [Page 11] Internet-Draft Internet(C) July 2004 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: o Regarding the country laws, an Internet server resource works just like a PRIVATE resource, with the exception that it is possible to create new versions from it. However, by default no reproduction and no execution of these versions are allowed in no country. o Any version SHALL inherit the INTERNET modifier. The modifier has equivalent capabilities than the server resource (section 2.3). In other words, multiple versions of the same Internet resource can be exhibited by different rightsholders. o All Internet versions SHALL refer, directly or indirectly, to an original server resource. Any operation on a client version resource (even its exhibition or execution) may ultimately require the original rightsholder's authorization. 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. 3.4 PUBLIC modifier 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 Maturana & Robredo Expires December 30, 2004 [Page 12] Internet-Draft Internet(C) July 2004 rightsholder of the public resource keeps the full control on the resource. 3.5 Scope inheritance 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: o Internet and public client resources can degrade to private because they recognize a separate ownership. o The client of a public resource can freely degrade to any scope. This is done without prejudice to server rightsholder, who has explicitly allowed the transformation and the reproduction of the client resources. This document does not define precedence rules for scope modifiers. Maturana & Robredo Expires December 30, 2004 [Page 13] Internet-Draft Internet(C) July 2004 4. Syntax of ownership declarations 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. 4.1 Formal declaration 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. o Property line. MUST appear. It contains the rightsholder's declaration of the resource. o Attribution line(s). SHALL appear in client resource declarations. It refers to the rightsholder's declaration of a server resource. o License line. Optional. Free text or link that defines specific conditions of ownership. 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. Maturana & Robredo Expires December 30, 2004 [Page 14] Internet-Draft Internet(C) July 2004 4.2 Property line Property line MUST appear for all modifiers. The Property line is composed of: o The scope modifier, from the token list: Private, Protected, Public, Internet. o The (C) symbol. This symbol may be entered as a parenthesized C, uppercase or lowercase. o The Date of first exhibition, usually followed by the date of the last update o The Name of the resource rightsholder o Any optional information, as the resource URL or the author's email address. 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) 4.3 Attribution line 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 Maturana & Robredo Expires December 30, 2004 [Page 15] Internet-Draft Internet(C) July 2004 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] 4.4 License line 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. Maturana & Robredo Expires December 30, 2004 [Page 16] Internet-Draft Internet(C) July 2004 Internet(C) 2004, OwnerX (owner-x@somesite.com) LGTv1r4: http://www.in3activa.org 4.5 Long names and short names of modifiers 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. Maturana & Robredo Expires December 30, 2004 [Page 17] Internet-Draft Internet(C) July 2004 5. Scope modifiers implementation 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. 5.1 Handwritten implementation: the default modifier 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 ... 5.2 HTML implementation: the SCOPE tag 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], 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: o A SCOPE meta tag in the HEAD section, which defines the default scope of the resource. o Optionally, one or more scope tags in the body, which override the default scope defined in the header. The following example describes a protected HTML resource: Maturana & Robredo Expires December 30, 2004 [Page 18] Internet-Draft Internet(C) July 2004 ... ...
             ...
          
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: ... or ... 5.3 Dublin Core implementation 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]. The addition is based on a new SCOPE element, to be used along with the already defined Rights Element: Maturana & Robredo Expires December 30, 2004 [Page 19] Internet-Draft Internet(C) July 2004 Le ravissement d'Europe
             ...
          
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 5.4 Using licenses 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 Maturana & Robredo Expires December 30, 2004 [Page 20] Internet-Draft Internet(C) July 2004 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. Maturana & Robredo Expires December 30, 2004 [Page 21] Internet-Draft Internet(C) July 2004 6. Security Considerations None. 7 References [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, . Maturana & Robredo Expires December 30, 2004 [Page 22] Internet-Draft Internet(C) July 2004 Authors' Addresses I.Maturana in3activa Aptdo 15.117 Madrid, Spain I.Robredo in3activa Ziburu, France Maturana & Robredo Expires December 30, 2004 [Page 23] Internet-Draft Internet(C) July 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. Maturana & Robredo Expires December 30, 2004 [Page 24]