idnits 2.17.1 draft-popp-cnrp-00.txt: -(52): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 690 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 11 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RDF' is mentioned on line 179, but not defined == Unused Reference: 'RDFSchema' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'XML' is defined on line 651, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'METADATA' -- Possible downref: Non-RFC (?) normative reference: ref. 'DC' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLNAMESPACES' -- Possible downref: Non-RFC (?) normative reference: ref. 'RDFSCHEMAS' -- Possible downref: Non-RFC (?) normative reference: ref. 'RDFSchema' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Nicolas Popp 2 draft-popp-cnrp-00.txt Centraal Corporation 3 February 14, 1999 Michael Mealling 4 Expires August 1999 Network Solutions 6 A resolution protocol for Common Name Namespaces 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 People often refer to things in the world by a common name 33 or phrase, e.g., a trade name, company name, or a book title. 34 These names are sometimes easier for people to remember and 35 enter than URLs; many people consider URLs hard to remember 36 or type. 38 This document proposes an abstract protocol for the resolution of 39 common names. The protocol is based on XML, RDF and the Dublin 40 Core metadata elements. The proposed mechanism allows for a very 41 dynamic resolution process where the client has no predefined 42 knowledge of the namespace or the resolution service. The protocol 43 supports an extensible query and response interface with multiple 44 independent XML vocabularies. Furthermore, it allows for multiple 45 concrete implementations (HTTP, LDAP, WHOIS,...). Both the specifics 46 of the query interface and the type of implementation can be 47 discovered at runtime by the resolution client. 49 This document is intended for discussion at the Common Name 50 Resolution Protocol BOF (renamed from Human Friendly Identifier 51 BOF). It may be discussed on cnrp-ietf@lists.internic.net. Send in 52 body �subscribe cnrp-ietf� to listserv@lists.internic.net. The mail 53 archive is at http://lists.netsol.com/lists/cnrp. 55 1. Introduction: The common name as resource metadata 57 A CN is a common name used to access a resource on the Internet. 58 A resource can be an HTML Web page, a person's email address, a 59 downloadable software program, basically any type of addressable 60 objects that can reside on a network. In this discussion, any 61 network entity that has an URI [URI] qualifies as a "resource". 63 The CN is only one of the many characteristics of the resource. 64 For instance, The URI for the resource is another characteristic. 65 Descriptive information about a resource is called metadata 66 [METADATA]. Therefore, a CN is an element of metadata, or metadata 67 property. In addition to a name or a URI, a wide variety of 68 metadata properties are necessary to properly characterize a 69 resource. For example, when the resource is a Web page, a critical 70 piece of information for the user is the "language" of the Web 71 page. 73 Since a CN will generally not be unique across a namespace, it is 74 important to have other properties to identify a specific 75 resource. For instance, the CN "BMW" can be associated with the 76 Web page at http://www.bmw.com, the official BMW homepage for the 77 English language. At the same time, the CN "BMW" can also be 78 associated with the Web page at http://www.bmw.de, the official 79 homepage for BMW in the German language. As a namespace grows to 80 encompass several thousands of names, it becomes necessary to 81 introduce other metadata properties. These properties are used to 82 give structure to the namespace so that resources can be precisely 83 referred to. 85 Therefore, it is important to think of a Common Name as one 86 property of a larger metadata object. In that context, a Common 87 Name namespace is a multidimensional space of metadata vectors 88 where each unique property defines a dimension. In such space, 89 finding all the vectors that meet some specific requirements is 90 called the resolution process. 92 This means that in order to define a general resolution protocol, 93 we first need to consider which properties can be part of the 94 namespace. In fact, these properties may have to be exposed in the 95 resolution query. Hence, the set of admissible properties needs to 96 be understood before a protocol can be developed. The answer to 97 this question is actually straightforward since the resolution 98 protocol should be flexible to support ANY property as part of the 99 query interface. This even includes properties that are unique to 100 a single namespace. 102 Nevertheless, from a practical standpoint, we believe that there 103 exists a set of core properties that will be present in most 104 namespaces. These properties are the Dublin Core metadata 105 properties [DC]. Although it should not be required that a 106 namespace supports any of these properties, we expect them to play 107 a key role in standard implementations. We expect that many 108 namespaces will standardize on the Dublin Core properties to 109 increase interoperability. At a minimum, we recommend namespace 110 implementers to study the Dublin Core elements before introducing 111 new and proprietary vocabulary. Lastly and to illustrate the use 112 of the query protocol, we will use the Dublin Core properties in 113 all our examples for the remaining of this document. 115 To formalize our discourse, we define a Common Name namespace as a 116 set metadata. A record in the Common Name namespace database is 117 represented as a metadata vector (or a point) in that space with 118 each meta property defining a new dimension (or axis). Thus, a 119 namespace can be represented as a set of tuples {(P1, P2, ..., Pm)} 120 where Pi (i=1,m) are the meta properties defined by the namespace. 121 An element of the namespace is written as a tuple E (e1, e2, ..., 122 em) where ei (i=1,m) is the value of the ith property for the 123 namespace element. 125 As an example, let us consider a namespace for Web pages with 4 126 properties. Let these four properties be: CN:CN (the Common Name), 127 DC:IDENTIFIER (the Dublin Core identifier element, the URI for the 128 resource), DC:LANGUAGE (the Dublin Core language element) and 129 DC:DESCRIPTION (the Dublin Core description element). An XML 130 namespace [XMLNAMESPACES] for Common Names (prefixed CN) is 131 presented in the next section. DC is the XML namespace prefix for 132 the Dublin Core properties. This namespace can be represented as 133 {(CN:CN, DC:IDENTIFIER, DC:LANGUAGE, DC:DESCRIPTION)}. Using our 134 notation, an example of an entry for this namespace is ("BMW", 135 "en", http://www.bmw.com, "The homepage for BMW, German car 136 maker."). 138 2. A simple abstract protocol for the resolution service: 140 This section describes a generic resolution service for Common 141 Name namespaces. An abstract protocol for the resolution service 142 is proposed. The protocol assumes that all namespaces must 143 implement a minimum of two properties: the CN and the URI 144 properties. 146 The resolution service is responsible to resolve a query into a 147 list of meta entries or namespace elements. For that purpose, the 148 query interface is explicitly limited and kept as simple as 149 possible. The resolution query interface is defined as a 150 conjunctive query of property-value pairs. The properties allowed 151 in the query are called the query parameters. The resolution 152 protocol presented requires the CN to always be exposed in the 153 query interface. This constraint guarantees that a first order 154 implementation of the protocol exclusively relying on the CN will 155 always work across all namespace implementations. Other properties 156 present in the namespace can be added to the query interface. The 157 namespace authority is solely responsible for deciding which 158 properties to publicly expose as part of the query interface of 160 the resolution service. The mechanisms for publishing and 161 discovering query properties is described in section 3. 163 Using the notations introduced previously, for a namespace of m 164 meta properties {(P1, P2, ..., Pm)}, a query Q can be formalized as 165 the tuple Q of property-value pairs: 167 Q = (Pq1 = v1, Pq2 = v2, ..., Pqi = vi) where (1 <= i <= m) and for 168 each i, 1 <= qi <= m. Each vi is the desired value of the (qi)th 169 property for an entry of the namespace to match the resolution 170 query. 172 For such a query, the resolution service will return a set of r 173 tuples where each tuple Ej (ej1, ...ejm), (1 <= j <= r) is such that 174 for each qi (1 <= i <= m), ejqi = vi. In other terms, each tuple 175 Ej of the result set satisfies all the conjuncts in the query. 176 Since the response is a results set of metadata, we suggest that 177 the response to a resolution query always be contained in the RDF 178 data model. One encoding of the RDF data model is based on XML 179 [RDF] 181 Note the following explicit restrictions for the resolution 182 service query interface: The query is limited to conjunctive 183 atomic queries where an atomic query is in the form "property name 184 = property value". The only operator supported by this simple 185 query interface is the "equal" operator. The actual semantic of 186 "equality" will depend on the qualified property (the property 187 type). 189 For instance, the equality between two Common Names will require 190 more than a byte to byte straight comparison (e.g. UNICODE string 191 equivalence). Beyond the resolution service, we anticipate other 192 services such as "search" services. One can guess that these 193 services will extend the query language to include more elaborate 194 forms of queries (such as Boolean queries and relevance ranking). 196 For our namespace example {(CN:NAME, DC:IDENTIFIER, DC:LANGUAGE, 197 DC:DESCRIPTION)}, the query for the resource associated with the 198 Common Name "BMW" in the English language will be written as: 200 Q = (CN:CN = "BMW", DC:LANGUAGE = "en"). 202 For such query, the response returned by the resolver would be a 203 list of namespace elements such as: 205 { 206 ("BMW", "en", http://www.bmw.com, "The homepage for BMW."), 207 ("BMW", "de", http://www.bmw.de, "BMW Deutschland.") 208 } 210 Note that the CN XML namespace is introduced in more details in 211 section 2 of this document and the exact form of the RDF response 212 is presented in section 4. 214 3. An RDF schema for common name namespaces 216 To support the dynamic definition of all parameters involved in 217 the resolution protocol, we introduce a formal RDF schema 218 [RDFSCHEMAS]. This schema formally defines the Common Name as a 219 core RDF property for CN namespaces. 221 225 This defines the Common Name (CN) as a resource 226 property 228 229 231 Common Name 232 234 Furthermore, to enable the dynamic discovery of query and response 235 properties, the schema introduces the concepts of resolution Query 236 and resolution Response. 238 A superclass for all resolution 239 queries. 241 242 244 246 248 A superclass for all resolution 249 responses. 251 252 254 256 258 The Query class encapsulates the resolution query whereas the 259 Response class encapsulates the resolution response. The CN is a 260 required query property for ALL resolution services. The 261 DC:IDENTIFIER is the only required property for the response. To 262 expose more properties in the query or the response each namespace 263 can extend (subclass) the Query or the Response class. 265 To allow for a precise definition of the query and response 266 parameters, the RDF schema introduces the "parameters" property. 267 This property is scoped to the Query and Response classes. Its 268 value is an unordered list of admissible property classes. 270 The parameters property allows a namespace to 271 specify the list of properties that belong to the query or to the 272 response of their resolution service. 274 275 277 278 279 281 283 Using this new property, we can now translate the resolution query 284 and response interface constraints into simple RDF statements 285 about the Query and Response classes: 287 The following statement makes the CN property part 288 of all resolution query interfaces. 290 291 292 293 294 295 296 298 The following statement makes the DC:IDENTIFIER 299 property part of all resolution responses. 301 302 303 304 306 307 308 310 Lastly, we complete the CN RDF schema with the notion of 311 ResolutionService. The ResolutionService class encapsulates the 312 main parameters of an actual implementation of the resolution 313 service. Its first property is the queryInterface. The 314 queryInterface defines the class to be used by the client in order 315 to form a valid resolution query. Thus, the queryInterface is a 316 property whose value is of Class Query (or a subclass). The 317 queryInterface property allows a namespace authority to define the 319 subclass of Query to use with their resolution service, hence to 320 express which other properties beside the CN should be part of the 321 resolution query interface. The second property of 322 ResolutionService is the responseInterface. Symmetrically, the 323 responseInterface is a property whose value is of Class Response. 324 It allows a namespace authority to fully specify the format of the 325 resolution response. 327 A class for all Resolution services 329 330 332 334 336 An instance of the class ResolutionService uses the 337 queryInterface property to specify to the client which Query class 338 to use for resolution queries. The value of this property is a 339 Class (Query or a subclass of Query) 341 342 344 345 347 349 An instance of the class ResolutionService uses the 350 responseInterface property to specify to the client which Response 351 class to expect for the response. The value of this property is a 352 Class (Response or a subclass of Response) 354 355 357 358 360 362 364 The presented RDF schema defines the core objects and vocabulary 365 for all CN namespaces. Using this schema, each namespace can now 366 create its own RDF file. This new RDF file is owned, published and 367 maintained by the namespace authority. It is called the namespace 368 file. The idea behind the namespace file is to allow each 369 namespace organization to expose the specifics of their own 370 namespace. This includes the type of properties that are part of 371 the namespaces, the properties exposed in the resolution query or 373 response interface, and the implementation parameters for the 374 resolution service (see section 4 of this document for 375 implementation parameters). 377 The following example shows how a namespace can use the RDF 378 namespace file to expose any set of properties in the query 379 interface of its resolution service. Let us consider our namespace 380 example: {(CN:CN, DC:IDENTIFIER, DC:LANGUAGE, DC:DESCRIPTION)}. 381 Let us also assume that we would like to expose {CN:CN, 382 DC:LANGUAGE} in the resolution query interface. Lastly, let us 383 assume that the response is the default Resolution response as 384 specified in the CN schema. Under these conditions, the namespace 385 file will be written: 387 393 A subclass of Query to expose the dc:language 394 property as part of the resolution query interface 396 397 399 401 403 Stipulate that the DC:LANGUAGE property is supported 404 by MyQuery. Since MyQuery is a subclass of Query, cn:cn is 405 supported as well. 407 408 409 410 412 413 414 416 Create an instance of 417 ResolutionService 419 421 Specify to the client that it must pass resolution 422 queries of class MyQuery and expect responses of class Response. 423 425 426 427 429 431 433 It is clear that this mechanism provides infinite flexibility for 434 customizing the query and response interfaces. In particular, the 435 properties exposed by the query or the response are not limited to 436 the Dublin Core but can involve any XML vocabulary. The only 437 constraint lies in the publication of the RDF namespace file, a 438 relatively straightforward task as demonstrated in our example. 440 4. A schema compliant RDF representation for the resolution query and 441 response. 443 Now that an RDF schema has been defined, it is possible to 444 formally express both the resolution query and response as RDF. 445 The XML encoding of this representation is the recommended 446 transfer mechanism between the client and the server. 448 For a namespace that is satisfied with the default query interface 449 (as specified in the RDF schema), the format of the query is 450 extremely simple and the same for all namespaces. For example, the 451 "default" query for the Common Name "BMW cars" can be written: 453 457 458 459 BMW 460 461 463 Using the Response class formalized by the RDF schema, the 464 response to our example query can simply be written as: 466 470 471 472 473 474 475 BMW 476 en 477 BMW Homepage 478 479 480 481 482 BMW 483 de 484 BMW Deutschland 485 486 487 488 489 491 Since this format will be understood by all namespaces, a trivial 492 client implementation of the protocol is possible. The default 493 query form makes it very simple to use any resolver on the 494 network, independently of the namespace. At the same time, if the 495 targeted namespace has published its own RDF file derived from the 496 schema, and if the client wants to take advantage of the richer 497 APIs, a more advanced implementation is possible. 498 For example, let us assume now that a client wants to access the 499 resolver from our example namespace. Let us also assume that it 500 wants to use the language property in the query in order to 501 restrict the results set to Web pages in the English language. 502 This translates into the query Q = (CN:CN = "BMW", DC:LANGUAGE = 503 "en"). Q can now be precisely encoded using the class MyQuery 504 found in the RDF namespace file 506 511 512 513 BMW 514 en 515 516 518 In conclusion, we have defined a formal RDF representation for the 519 resolution query and response. The resolver client can infer the 520 exact RDF representation of the query and response at runtime. 521 This exact representation is derived from an RDF file and can 522 differ from one namespace to another (through the definition of a 523 specific subclass of cn:Query and cn:Response). 525 5. An implementation of the abstract protocol using HTTP/XML/RDF. 527 In section 2, we have defined an abstract protocol that can 528 support a wide variety of implementations. In particular, it is 529 worth noting that the abstract resolution protocol could be 530 implemented using LDAP, WHOIS or HTTP. Because of its popularity 531 and simplicity, we anticipate that HTTP will provide the most 532 popular implementation. For that reason, this section specifically 533 looks at a concrete implementation based on HTTP. 535 HTTP is the transport mechanism. The resolution request is 536 expressed in RDF, encoded in XML and embedded within the HTTP 537 request. To answer the request, a resolver generates an RDF 538 document which is returned to the client within the HTTP response. 540 In order for a namespace to specify the concrete types of 541 implementations that it supports, the ResolutionService class 542 introduced in section 3 of this document is made an abstract 543 superclass. Hence, the Implementation class becomes a base class 544 from which specific subclasses can be derived in order to describe 545 a concrete implementation. In the case of the HTTP implementation 546 of the resolution service, the concrete subclass is called 547 HTTPResolutionService. This class allows the specification of 548 physical parameters such as the HTTP server URI or the Web server 549 port number. 551 In the CN schema, these notions translate into: 553 A concrete subclass of ResolutionService to support 554 an HTTP implementation of the protocol. 556 557 559 560 562 The resolver port number, a property of the 563 HTTPResolutionService class 565 566 568 569 571 573 To understand how these new notions will be used, let us consider 574 our example namespace. Let us assume that the resolution service 575 for this namespace is implemented using HTTP. To indicate an HTTP 576 implementation of the service to the resolution clients, the 577 namespace administrator simply adds an instance of 578 HTTPResolutionService to the RDF namespace file: 580 Here, we fully specify the resolution service for 581 our example namespace. In particular, it includes the description 582 for the HTTP implementation 584 586 587 588 590 http://www.mycnexample.com/cgi- 591 bin/resolver 592 80 593 595 This is significant since a client can dynamically discover the 596 type of implementation supported by a specific namespace. It is 597 then up to this client to make a decision regarding which 598 implementation it should access (HTTP, LDAP, WHOIS,...). Everything 599 can happen at runtime since the client can learn the 600 implementation specific parameters as well as the resolution query 601 interface for each particular namespace. 603 This shows that the resolution process can be extremely dynamic 604 with no predefined knowledge of the namespace. In fact, the only 605 required knowledge for the client is the URI for the RDF namespace 606 file. It is therefore conceivable that these URIs would be 607 registered with a central authority. 609 6. Conclusion 611 This document presented a protocol for Common Name resolution. A 612 resolution query has been defined as a conjunctive query of key 613 value pairs. An RDF schema has been introduced. The schema 614 introduces the minimal vocabulary and concepts necessary to 615 provide enough flexibility for dealing with multiple namespaces. 616 Using this schema, the resolution query and response have been 617 expressed using RDF. The notion of a distributed namespace file 618 (one per namespace) has been discussed. This file allows the 619 introduction of arbitrary vocabulary for the resolution query and 620 response interfaces. Furthermore, it allows for multiple concrete 621 implementations of the resolution protocol. Leveraging this file, 622 a resolution client can dynamically discover the implementation 623 details of a targeted resolution service. The client can then use 624 this knowledge to adapt to the implementation. A default form and 625 implementation of the protocol that does not require access to a 626 namespace file has also been presented. 628 7. References 630 [URI] Uniform Resource Identifiers (URI): Generic Syntax; Berners- 631 Lee, Fielding, Masinter, Internet Draft Standard August, 1998; 632 RFC2396. 634 [METADATA] Metadata and Resource description; 635 http://www.w3.org/Metadata/ 637 [DC] The Dublin Core initiative; 638 http://purl.oclc.org/metadata/dublin_core 640 [XMLNAMESPACES] Namespaces in XML; Bray, Hollander, Layman eds, 641 World Wide Web Consortium Working Draft; 642 http://www.w3.org/TR/1998/PR-xml-names-19981117. 644 [RDFSCHEMAS] Resource Description Framework (RDF) Model and 645 Syntax; http://www.w3.org/TR/WD-rdf-syntax/ 647 [RDFSchema] Resource Description Framework (RDF) Schemas; 648 Brickley, Guha, Layman eds., World Wide Web Consortium Working 649 Draft; http://www.w3.org/TR/WD-rdf-schema 651 [XML] Extensible Markup Language (XML) 1.0; World Wide Web 652 Consortium Recommendation; http://www.w3.org/TR/REC-xml. 654 8. Authors Addresses: 656 Nicolas Popp Centraal Corporation 811 Hansen Way PO Box 50750 Palo 657 Alto CA 94303 0750 U.S.A. Phone: (650)846-3615 Fax: (650)858-0454 658 Email: nico@centraal.com 660 Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon, 661 VA 22070 voice: (770) 935-5492 fax: (703) 742-9552 email: 662 michaelm@netsol.com 664 Expires 8/14 1999 665 A resolution protocol for Common Name Namespaces February 1999