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