From owner-urn-ietf@LISTS.NETSOL.COM Mon Jan 14 08:21:58 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02243 for ; Mon, 14 Jan 2002 08:21:57 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA11811; Mon, 14 Jan 2002 08:17:51 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5298 for URN-IETF@LISTS.NETSOL.COM; Mon, 14 Jan 2002 08:17:02 -0500 Received: from zark.ecotroph.net (64.83.37.226.dsl226-static-nova.cavtel.net [64.83.37.226]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA11804 for ; Mon, 14 Jan 2002 08:16:58 -0500 (EST) Received: from thinkingcat.com ([::ffff:24.168.219.159]) (AUTH: LOGIN leslie, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zark.ecotroph.net with esmtp; Mon, 14 Jan 2002 07:39:46 -0500 X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------727F5B1C6D382826554E9D66" Approved-By: Leslie Daigle Message-ID: <3C42D845.F89F61C2@thinkingcat.com> Date: Mon, 14 Jan 2002 08:08:21 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Revised RFC2611bis document to be published To: URN-IETF@LISTS.NETSOL.COM This is a multi-part message in MIME format. --------------727F5B1C6D382826554E9D66 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Howdy, FYI, here is a copy of the revised draft-ietf-urn-rfc2611bis-04.txt document. The only changes that have been made are: . updated to current DDDS document references . addition of Appendix C, documenting changes to the RFC2611 document, at the request of the IESG. It should hit the repository any day... Leslie. -- ------------------------------------------------------------------- "An essential element of a successful journey is recognizing when you have arrived." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- --------------727F5B1C6D382826554E9D66 Content-Type: text/plain; charset=iso-8859-1; name="nsmailCS.TMP" Content-Disposition: inline; filename="nsmailCS.TMP" Content-Transfer-Encoding: quoted-printable Internet-Draft L. Dai= gle URN WG Thinking Cat Enterpri= ses Expires July 13, 2002 D. van Gu= lik Category: Best Current Practice WebWeav= ing draft-ietf-urn-rfc2611bis-04.txt R. Ianne= lla IPR Syst= ems P. Faltst= rom Ci= sco January 13, 2= 002 URN Namespace Definition Mechanisms Status of this Memo This document is an Internet-Draft and is in full conformance wi= th all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineerin= g 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- Dra= fts 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 Abstract The URN WG has defined a syntax for Uniform Resource Names (URNs) [RFC2141], as well as some proposed mechanisms for their resolutio= n and use in Internet applications ([RFCXXXX], [RFCYYYY]). The whol= e rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed ([RFC2288]), and t= his document lays out general definitions of and mechanisms for establishing URN "namespaces". This document obsoletes RFC2611. Discussion of this document should be directed to urn-ietf@ietf.or= g Daigle [Page= 1] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 Table of Contents Abstract ........................................................ = 1 Table of Contents ............................................... = 2 1.0 Introduction ................................................ = 2 2.0 What is a URN Namespace? .................................... = 3 3.0 URN Namespace (Registration) Types .......................... = 4 3.1 Experimental Namespaces ..................................... = 4 3.2 Informal Namespaces ......................................... = 4 3.3 Formal Namespaces ........................................... = 4 4.0 URN Namespace Registration, Update, and NID Assignment Process ..................................................... = 6 4.1 Experimental ................................................ = 6 4.2 Informal .................................................... = 7 4.3 Formal ...................................................... = 7 5.0 Security Considerations ..................................... = 9 6.0 IANA Considerations ......................................... = 9 7.0 References .................................................. = 9 8.0 Authors' Addresses .......................................... = 10 9.0 Appendix A -- URN Namespace Definition Template ............. = 11 10.0 Appendix B -- Illustration ................................. = 15 10.1 Example Template ........................................... = 15 10.2 Registration steps in practice ............................. = 17 11.0 Appendix C -- Changes from RFC2611 ......................... = 18 11.1 Detailed Document Changes .................................. = 19 1.0 Introduction Uniform Resource Names (URNs) are resource identifiers with the specific requirements for enabling location independent identification of a resource, as well as longevity of reference. There are 2 assumptions that are key to this document: Assumption #1: Assignment of a URN is a managed process. I.e., not all strings that conform to URN syntax are necessaril= y valid URNs. A URN is assigned according to the rules of a particular namespace (in terms of syntax, semantics, and proces= s). Assumption #2: The space of URN namespaces is managed. I.e., not all syntactically correct URN namespaces (per the URN syntax definition) are valid URN namespaces. A URN namespace must have a recognized definition in order to be valid. Daigle [Page= 2] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 The purpose of this document is to outline a mechanism and provide= a template for explicit namespace definition, along with the mechani= sm for associating an identifier (called a "Namespace ID", or NID) wh= ich is registered with the Internet Assigned Numbers Authority, IANA. Note that this document restricts itself to the description of processes for the creation of URN namespaces. If "resolution" of = any so-created URN identifiers is desired, a separate process of registration in a global NID directory, such as that provided by t= he DDDS system [RFCXXXX], is necessary. See [RFCYYYY] for informatio= n on obtaining registration in the DDDS global NID directory. 2.0 What is a URN Namespace? For the purposes of URNs, a "namespace" is a collection of uniquel= y- assigned identifiers. That is, the identifiers are not ever assig= ned to more than 1 resource, nor are they ever re-assigned to a differ= ent resource. A single resource, however, may have more than one URN assigned to it for different purposes. A URN namespace itself has= an identifier in order to - ensure global uniqueness of URNs - (where desired) provide a cue for the structure of the identifier For example, many identifier systems make use strings of numbers a= s identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable t= hat there might be some numbers that are valid identifiers in two different established identifier systems. Using different designators for the two collections ensures that no two URNs will = be the same for different resources (since each collection is require= d to uniquely assign each identifier). The development of an identifier structure, and thereby a collecti= on of identifiers, is a process that is inherently dependent on the requirements of the community defining the identifier, how they wi= ll be assigned, and the uses to which they will be put. All of these issues are specific to the individual community seeking to define = a namespace (e.g., publishing community, association of booksellers, protocol developers, etc); they are beyond the scope of the IETF U= RN work. This document outlines the processes by which a collection of identifiers satisfying certain constraints (uniqueness of assignme= nt, etc) can become a bona fide URN namespace by obtaining a NID. In = a nutshell, a template for the definition of the namespace is comple= ted for deposit with IANA, and a NID is assigned. The details of the Daigle [Page= 3] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 process and possibilities for NID strings are outlined below. 3.0 URN Namespace (Registration) Types There are 3 categories of URN namespaces defined here, distinguish= ed by expected level of service and required procedures for registration. Registration processes for each of these namespace types are given in Section 4.0. 3.1 Experimental Namespaces These are not explicitly registered with IANA. They take the form X- No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts. 3.2 Informal Namespaces These are fully fledged URN namespaces, with all the rights and requirements associated thereto. Informal namespaces can be registered in global registration services. They are required to uphold the general principles of a well-managed URN namespace -- providing persistent identification of resources, and unique assignment of identifier strings. Informal and formal namespaces (described below) differ in the NID assignment. IANA will assign = an alphanumeric NID to registered informal namespaces, per the proces= s outlined in Section 4.0. 3.3 Formal Namespaces A formal namespace may be requested, and IETF review sought, in ca= ses where the publication of the NID proposal and the underlying namespace will provide benefit to some subset of users on the Internet. That is, a formal NID proposal, if accepted, must be functional on and with the global Internet, not limited to users i= n communities or networks not connected to the Internet. For example= , a NID is requested that is meant for naming of physics research. If that NID request required that the user use a propietary network o= r service that was not at all open to the general Internet user then= it would make a poor request for a formal NID. The intent is that, wh= ile the community of those who may actively use the names assigned wit= hin that NID may be small (but no less important), the potential use o= f Daigle [Page= 4] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 names within that NID is open to any user on the Internet. It is expected that Formal NIDs may be applied to namespaces where some aspects are not fully open. For example, a namespace may make use of a fee-based, privately managed, or proprietary registry for assignment of URNs in the namespace, but it may still provide bene= fit to some Internet users if the services associated have openly- published access protocols. In addition to the basic registration information defined in the registration template (in Appendix A), a formal namespace request must be accompanied by documented considerations of the need for a new namespace and the community benefit of formally establishing t= he proposed URN namespace. Additionally, since the goal of URNs is to provide persistent identification, some consideration as to the longevity and maintainability of the namespace must be given. The URN WG discus= sed at length the issue of finding objective measures for predicting (= a priori) the continued success of a namespace. No conclusion was reached -- much depends on factors that are completely beyond the technical scope of the namespace. However, the collective experie= nce of the IETF community does contain a wealth of information on technical factors that will prevent longevity of identification. = The IESG may elect not to publish a proposed namespace RFC if the IETF community consensus is that it contains technical flaws that will prevent (or seriously impair the possibility of) persistent identification. The kinds of things the URN WG discussed included: - the organization maintaining the URN namespace should demonstrate stability and ability to maintain the URN namespa= ce for a long time, and/or it should be clear how the namespace = can continue to be usable/useful if the organization ceases to be able to foster it; - it should demonstrate ability and competency at name assignme= nt in order to facilitate persistence (e.g. to minimize the likelihood of conflicts); - it should commit to not re-assigning existing names and allow= ing old names to continue to be valid, even if the owners or assignees of those names are no longer members or customers o= f that organization. This does not mean that there must be resolution of such names, but it does mean that they must not resolve the name to false or stale information, and it means that they must not be reassigned. Daigle [Page= 5] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 These aspects, though hard to quantify objectively, should be considered by organizations/people considering the development of = a Formal URN namespace, and they will be kept in mind when evaluatin= g the technical merits of any proposed Formal namespace. 4.0 URN Namespace Registration, Update, and NID Assignment Process Different levels of disclosure are expected/defined for namespaces= . According to the level of open-forum discussion surrounding the disclosure, a URN namespace may be assigned or may request a particular identifier. The "IANA Considerations" document [RFC24= 34] suggests the need to specify update mechanisms for registrations -= - who is given the authority to do so, from time to time, and what a= re the processes. Since URNs are meant to be persistently useful, fe= w (if any) changes should be made to the structural interpretation o= f URN strings (e.g., adding or removing rules for lexical equivalenc= e that might affect the interpretation of URN IDs already assigned). However, it may be important to introduce clarifications, expand t= he list of authorized URN assigners, etc, over the natural course of = a namespace's lifetime. Specific processes are outlined below. The official list of registered URN namespaces is maintained by IA= NA. URN namespace registrations are currently being posted in the anonymous FTP directory ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/ See [STD2] for the current location of IANA registry. The registration and maintenance procedures vary slightly from one namespace type (as defined in Section 3.0) to another. 4.1 Experimental These are not explicitly registered with IANA. They take the form X- No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts. As there is no registration, no registration maintenance procedure= s are needed. Daigle [Page= 6] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 4.2 Informal These are registered with IANA and are assigned a number sequence = as an identifier, in the format: "urn-" where is chosen by the IANA on a First Come First Served basis (see [RFC2434]). Registrants should send a copy of the registration template (see Appendix A), duly completed, to the urn-nid@apps.ietf.org mailing and allow for a 2 week discussion period for clarifying th= e expression of the registration information and suggestions for technical improvements to the namespace proposal. After suggestions for clarification of the registration informatio= n have been incorporated, the template may be submitted to: iana@iana.org for assignment of a NID. The only restrictions on are that it consist strictly of digits and that it not cause the NID to exceed length limitations outlined in the URN syntax ([RFC2141]). Registrations may be updated by the original registrant, or an ent= ity designated by the registrant, by updating the registration templat= e, submitting it to the discussion list for a further 2 week discussi= on period, and finally resubmitting it to IANA, as described above. 4.3 Formal Formal NIDs are assigned via IETF Consensus, as defined in [RFC243= 4]: "IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists)." Thus, the Formal NID application is made via publication of an RFC through standard IETF processes. The RFC need not be standards- Daigle [Page= 7] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 track, but it will be subject to IESG review and acceptance pursua= nt to the guidelines written here (as well as standard RFC publicatio= n guidelines). The template defined in Appendix A may be included a= s part of an RFC defining some other aspect of the namespace, or it = may be put forward as an RFC in its own right. The proposed template should be sent to the urn-nid@apps.ietf.org mailing list to allow for a 2 week discussion period for clarifyi= ng the expression of the registration information, before the IESG reviews the document. The RFC must include a "Namespace Considerations" section, which outlines the perceived need for a new namespace (i.e., where exist= ing namespaces fall short of the proposer's requirements). Considerations might include: - URN assignment procedures - URN resolution/delegation - type of resources to be identified - type of services to be supported NOTE: It is expected that more than one namespace may serve the s= ame "functional" purpose; the intent of the "Namespace Considerations" section is to provide a record of the proposer's "due diligence" i= n exploring existing possibilities, for the IESG's consideration. The RFC must also include a "Community Considerations" section, wh= ich indicates the dimensions upon which the proposer expects its community to be able to benefit by publication of this namespace a= s well as how a general Internet user will be able to use the space = if they care to do so. Potential considerations include: - open assignment and use of identifiers within the namespace - open operation of resolution servers for the namespace (server) - creation of software that can meaningfully resolve and access services for the namespace (client) The RFC must include an "IANA Considerations" section, indicating that the document includes a URN NID registration that is to be entered into the IANA registry of URN NIDs. A particular NID string is requested, and is assigned by IETF consensus (as defined in [RFC2434]), with the additional constrain= ts that the NID string must Daigle [Page= 8] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 - not be an already-registered NID - not start with "x-" (see Type I above) - not start with "urn-" (see Type II above) - not start with "XY-", where XY is any combination of 2 ASCII letters (see NOTE, below) - be more than 2 letters long NOTE: ALL two-letter combinations, and two-letter combinations followed by "-" and any sequence of valid NID characters, are reserved for potential use as countrycode- based NIDs for eventua= l national registrations of URN namespaces. The definition and scoping of rules for allocation of responsibility for such namespa= ces is beyond the scope of this document. Registrations may be revised by updating the RFC through standard IETF RFC update processes (see [RFC2606] for a discussion of IETF process). In any case, a revised document, in the form of a new Internet-Draft, must be published, and the proposed updated templa= te must be circulated on the urn-nid discussion list, allowing for a = 2 week review period before pursuing publication of the new RFC document. 5.0 Security Considerations This document largely focuses on providing mechanisms for the declaration of public information. Nominally, these declarations should be of relatively low security profile, however there is alw= ays the danger of "spoofing" and providing mis-information. Informati= on in these declarations should be taken as advisory. 6.0 IANA Considerations This document outlines the processes for registering URN namespace= s, and has implications for the IANA in terms of registries to be maintained. In all cases, the IANA should assign the appropriate = NID (informal or formal), as described above, once an IESG-designated expert has confirmed that the requisite registration process steps have been completed. This document defines processes to replace those outlined in [RFC2611]. 7.0 References [ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats - Information interchange - Representation of Daigle [Page= 9] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 dates and times" [RFC2026] Bradner, S., "The Internet Standards Process -- Revisi= on 3", RFC 2026, October 1996. [RFC2611] Daigle, L., D. van Gulik, R. Iannella, P. Faltstrom, "URN Namespace Definition Mechanisms", RFC 2611, June 1999. [RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing Bibliographic Identifiers as Uniform Resource Names", = RFC 2288, February 1998. [RFCXXXX] Mealling, M., "Dynamic Delegation Discovery System (DD= DS) Part One: The Comprehensive DDDS Standard", RFC XXXX. [RFCYYYY] Mealling, M., "Assignment Procedures for URI Resolutio= n Using DNS", RFCYYYY. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing = an IANA Considerations Section in RFCs", BCP 26, RFC 2434= , October 1998. [STD2] Reynolds, J, and J. Postel, "Assigned Numbers", STD = 2, October 1994. [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements = for Uniform Resource Names", RFC 1737, December 1994. [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998. 8.0 Authors' Addresses Leslie L. Daigle Thinking Cat Enterprises EMail: leslie@thinkingcat.com Dirk-Willem van Gulik WebWeaving Plein 1813 - 5a 8545 HX Arnhem Daigle [Page = 10] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 The Netherlands Phone: +39 0332 78 0014 (Phone and Fax) EMail: Dirkx@webweaving.org Renato Iannella IPR Systems Pty Ltd. EMail: renato@iprsystems.com Patrik Faltstrom Cisco Systems Inc 170 W Tasman Drive SJ-13/2 San Jose CA 95134 USA EMail: paf@cisco.com URL: http://www.cisco.com 9.0 Appendix A -- URN Namespace Definition Template Definition of a URN namespace is accomplished by completing the following information template. Apart from providing a mechanism = for disclosing structure of the URN namespace, this information is designed to be useful for - entities seeking to have a URN assigned in a namespace (if applicable) - entities seeking to provide URN resolvers for a namespace (if applicable) This is particularly important for communities evaluating the possibility of using a portion of an existing URN namespace rather than creating their own. Applications for Formal URN namespaces must also document "Namespa= ce Considerations", "Community Considerations" and "IANA Considerations", as described in Section 4.3. Information in the template is as follows: Namespace ID: Assigned by IANA. In the case of a Formal NID registration, a particular NID string may be requested. Daigle [Page = 11] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 Registration Information: This is information to identify the particular version of registration information: - registration version number: starting with 1, incrementing by= 1 with each new version - registration date: date submitted to the IANA, using the form= at YYYY-MM-DD as outlined in [ISO8601]. Declared registrant of the namespace: This includes: Registering organization Name Address Designated contact person Name Coordinates (at least one of: e-mail, phone, postal addre= ss) Declaration of syntactic structure: This section should outline any structural features of identifi= ers in this namespace. At the very least, this description may be used to introduce terminology used in other sections. This structure may also be used for determining realistic caching/shortcuts approaches; suitable caveats should be provid= ed. If there are any specific character encoding rules (e.g., which character should always be used for single-quotes), these shoul= d be listed here. Answers might include, but are not limited to: - the structure is opaque (no exposition) - a regular expressio= n for parsing the identifier into components, including naming authorities Relevant ancillary documentation: This section should list any RFCs, standards, or other publishe= d documentation that defines or explains all or part of the namespace structure. Answers might include, but are not limited to: - RFCs outlining syntax of the namespace - Other of the defining community's (e.g., ISO) documents Daigle [Page = 12] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 outlining syntax of the identifiers in the namespace - Explanatory material introducing the namespace Identifier uniqueness considerations: This section should address the requirement that URN identifiers b= e assigned uniquely -- they are assigned to at most one resource, an= d are not reassigned. (Note that the definition of "resource" is fairly broad; for examp= le, information on "Today's Weather" might be considered a single resource, although the content is dynamic.) Possible answers include, but are not limited to: - exposition of the structure of the identifiers, and partition= ing of the space of identifiers amongst assignment authorities wh= ich are individually responsible for respecting uniqueness rules - identifiers are assigned sequentially - information is withheld; the namespace is opaque Identifier persistence considerations: Although non-reassignment of URN identifiers ensures that a URN will persist in identifying a particular resource even after th= e "lifetime of the resource", some consideration should be given = to the persistence of the usability of the URN. This is particula= rly important in the case of URN namespaces providing global resolution. Possible answers include, but are not limited to: - quality of service considerations Process of identifier assignment: This section should detail the mechanisms and/or authorities fo= r assigning URNs to resources. It should make clear whether assignment is completely open, or if limited, how to become an assigner of identifiers, and/or get one assigned by existing assignment authorities. Answers could include, but are not limited to: - assignment is completely open, following a particular algorit= hm - assignment is delegated to authorities recognized by a particular organization (e.g., the Digital Object Identifier Foundation controls the DOI assignment space and its delegati= on) - assignment is completely closed (e.g., for a private Daigle [Page = 13] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 organization) Process for identifier resolution: If a namespace is intended to be accessible for global resoluti= on, it must be registerd in an RDS (Resolution Discovery System, se= e [RFC2276]) such as DDDS. Resolution then proceeds according to standard URI resolution processes, and the mechanisms of the RD= S. What this section should outline is the requirements for becomi= ng a recognized resolver of URNs in this namespace (and being so- listed in the RDS registry). Answers may include, but are not limited to: - the namespace is not listed with an RDS; this is not relevant - resolution mirroring is completely open, with a mechanism for updating an appropriate RDS - resolution is controlled by entities to which assignment has been delegated Rules for Lexical Equivalence: If there are particular algorithms for determining equivalence between two identifiers in the underlying namespace (hence, in = the URN string itself), rules can be provided here. Some examples include: - equivalence between hyphenated and non-hyphenated groupings i= n the identifier string - equivalence between single-quotes and double-quotes - Namespace-defined equivalences between specific characters, s= uch as "character X with or without diacritic marks". Note that these are not normative statements for any kind of be= st practice for handling equivalences between characters; they are statements limited to reflecting the namespace's own rules. Conformance with URN Syntax: This section should outline any special considerations required for conforming with the URN syntax. This is particularly applicable in the case of legacy naming systems that are used i= n the context of URNs. For example, if a namespace is used in contexts other than URNs= , it may make use of characters that are reserved in the URN synt= ax. Daigle [Page = 14] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 This section should flag any such characters, and outline necessary mappings to conform to URN syntax. Normally, this wi= ll be handled by hex encoding the symbol. For example, see the section on SICIs in [RFC2288]. Validation mechanism: Apart from attempting resolution of a URN, a URN namespace may provide mechanism for "validating" a URN -- i.e., determining whet= her a given string is currently a validly-assigned URN. There are 2 issues here: 1) users should not "guess" URNs in a namespace; 2) w= hen the URN namespace is based on an existing identifier system, it ma= y not be the case that all the existing identifiers are assigned on = Day 0. The reasonable expectation is that the resource associated wit= h each resulting URN is somehow related to the thing identified by t= he original identifier system, but those resources may not exist for each original identifier. For example, even if a telephone number- based URN namespace was created, it is not clear that all telephon= e numbers would immediately become "valid" URNs, that could be resol= ved using whatever mechanisms are described as part of the namespace registration. A validation mechanims might be: - a syntax grammar - an on-line service - an off-line service Scope: This section should outline the scope of the use of the identifiers in this namespace. Apart from considerations of private vs. public namespaces, this section is critical in evaluating the applicability of a requested NID. For example, = a namespace claiming to deal in "social security numbers" should have a global scope and address all social security number structures (unlikely). On the other hand, at a national level,= it is reasonable to propose a URN namespace for "this nation's soc= ial security numbers". 10.0 Appendix B -- Illustration 10.1 Example Template The following example is provided for the purposes of illustration= of the URN NID template described in Appendix A. Although it is base= d on a hypothetical "generic Internet namespace" that has been Daigle [Page = 15] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 discussed informally within the URN WG, there are still technical = and infrastructural issues that would have to be resolved before such = a namespace could be properly and completely described. Namespace ID: To be assigned Registration Information: Version 1 Date: Declared registrant of the namespace: Name: Thinking Cat Enterprises Address: 1 ThinkingCat Way Trupville, NewCountry Contact: L. Daigle E-mail: leslie@thinkingcat.com Declaration of structure: The identifier structure is as follows: URN::: where FQDN is a fully-qualified domain name, and the assigned string is conformant to URN syntax requirements. Relevant ancillary documentation: Definition of domain names, found in: P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATIO= N", RFC1035, November 1987. Identifier uniqueness considerations: Uniqueness is guaranteed as long as the assigned string is neve= r reassigned for a given FQDN, and that the FQDN is never reassigned. N.B.: operationally, there is nothing that prevents a domain n= ame from being reassigned; indeed, it is not an uncommon occurrenc= e. This is one of the reasons that this example makes a poor URN namespace in practice, and is therefore not seriously being proposed as it stands. Daigle [Page = 16] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 Identifier persistence considerations: Persistence of identifiers is dependent upon suitable delegatio= n of resolution at the level of "FQDN"s, and persistence of FQDN assignment. Same note as above. Process of identifier assignment: Assignment of these URNs delegated to individual domain name holders (for FQDNs). The holder of the FQDN registration is required to maintain an entry (or delegate it) in the DDDS. Within each of these delegated name partitions, the string may = be assigned per local requirements. e.g. urn::thinkingcat.com:001203 Process for identifier resolution: Domain name holders are responsible for operating or delegating resolution servers for the FQDN in which they have assigned URN= s. Rules for Lexical Equivalence: FQDNs are case-insensitive. Thus, the portion of the URN urn::: is case-insenstive for matches. The remainder of the identifie= r must be considered case-sensitve. Conformance with URN Syntax: No special considerations. Validation mechanism: None specified. Scope: Global. 10.2 Registration steps in practice The key steps for registration of informal or formal namespaces Daigle [Page = 17] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 typically play out as follows: Informal NID: 1. Complete the registration template. This may be done as par= t of an Internet-Draft. 2. Communicate the registration template to urn-nid@apps.ietf.o= rg for technical review -- as a published I-D, or text e-mail messa= ge containing the template. 3. Update the registration template as necessary from comments, = and repeat steps 2 and 3 as necessary. 4. Once comments have been addressed (and the review period has expired) end a request to IANA with the revised registration template. Formal NID: 1. Write an Internet-Draft describing the namespace and includin= g the registration template, duly completed. Be sure to include "Namespace Considerations", "Community Considerations" and "IANA Considerations" sections, as described in Section 4.3. 2. Send the Internet-Draft to the I-D editor, and send a copy to urn-nid@apps.ietf.org for technical review. 3. Update the Internet-Draft as necessary from comments, and rep= eat steps 2 and 3 as needed. 4. Send a request to the IESG to publish the I-D as an RFC. Th= e IESG may request further changes (published as I-D revisions) and/or direct discussion to designated working groups, area experts, etc. 5. If the IESG approves the document for publication as an RFC, send a request to IANA to register the requested NID. 11.0 Appendix C -- Changes from RFC2611 This revision of [RFC2611] adds more detail describing the process= of registering a URN namespace identifier (in terms of mechanical steps). This version of the document also separates the process (mechanics= ) from the discussion of the requirements for namespaces, attempting= to Daigle [Page = 18] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 make the latter as objective as possible. Throughout the document, references have been updated to the curre= nt versions of the DDDS and related documentation (which collectively obsolete [RFC2168] and related drafts). 11.1 Detailed Document Changes Added table of contents Section 2 Clarified the definition of a URN namespace, uniqueness of assignment, and that a single resource may have more than one identifier associated with it. Clarified the "number example" -- that the same string may appear = in 2 different namespaces, and be applied to different resources. Originally used ISBN/ISSN example, but structurally this is not possible. Section 3 (new) This section explicitly defines the 3 categories of namespace -- Experimental, Informal and Formal. This section provides a description of the intended use of the different namespace types, = as well as some acceptability guidelines for Formal namespaces (which require IETF review). Section 4.0 Spelled out the name of RFC2434 ("IANA Considerations"). Provided a pointer to the IANA URN namespace registry. Sections 4.1-4.3 new subsection divisions of the existing discussi= on of individual namespace types. Section 4.2 Corrected reference to URN Syntax document (RFC2141, not RFC2168). Daigle [Page = 19] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 Section 4.3 Added clarifying text as to the intended nature of Formal namespac= es and processes for registering them. Added text to describe the requirement for a "Namespace Considerations" section in RFCs defining Formal namespaces. Defin= ed the required content of that section. Added text to describe the new requirement for a "Community Considerations" section in RFCs defining Formal namespaces. Defin= ed the required content of that section. Added text to explicitly call out the need for an "IANA Considerations" section in such RFCs, in order to alert IANA to required action. Added text to further clarify the (IETF) process for revising Form= al namespace registrations through the RFC and IETF review process. Section 6 New section -- added text to describe the IANA considerations for this document. Section 7 -- References Added references to revised NAPTR documentation ([RFCXXXX]), and t= he previous version of this document ([RFC2611]). Section 9 -- Appendix A section created by moving the "URN Namespace Definition Template" (RFC2611's Section 3) to an appendix. Added references to the new requirements for "Namespace Considerations", "Community Considerations", and "IANA Considerations" sections for Formal namespace registrations. Clarified the "Declared registrant of the namespace" template element. Added text to describe the purpose and scope of the "Validating Mechanism". Daigle [Page = 20] =0C Internet-Draft draft-ietf-urn-rfc2611bis-04.txt May 2= 001 Section 10 -- Appendix B Section 10.1 is the "example template" that was "Section 5" in RFC2611. Update the sample "declared registrant" data per the changes to th= e template description. Removed the reference to "US-ASCII" in the "namespace specific string" of the example namespace. Section 10.2 (new) This added section is a step-by-step walkthrough of the process fo= r registering Informal namespaces and Formal namespaces. Daigle [Page = 21] --------------727F5B1C6D382826554E9D66-- From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 16 07:53:34 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05726 for ; Wed, 16 Jan 2002 07:53:33 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA21805; Wed, 16 Jan 2002 07:47:01 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5788 for URN-IETF@LISTS.NETSOL.COM; Wed, 16 Jan 2002 07:46:26 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA21798 for ; Wed, 16 Jan 2002 07:46:24 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0GCeI924182 for ; Wed, 16 Jan 2002 14:40:18 +0200 (EET) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jan 2002 14:40:16 +0200 Received: from [10.114.130.183] (tr-adsl-dhcp-130183.ntc.nokia.com [10.114.130.183]) by esebh01nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0ZYQ2Q0; Wed, 16 Jan 2002 14:40:16 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Wed, 16 Jan 2002 14:41:06 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit The following internet drafts have been submitted to the IETF for consideration: "An Extended Class Taxonomy for Uniform Resource Identifier Schemes" http://www-nrc.nokia.com/sw/draft-pstickler-uri-taxonomy-00.html "The 'hrn:' URI Scheme for Hierarchical Resource Names" http://www-nrc.nokia.com/sw/draft-pstickler-hrn-00.html "The 'uri:' URI Scheme for URI Reification" http://www-nrc.nokia.com/sw/draft-pstickler-uri-00.html "The 'tdl:' URI Scheme for Typed Data Literals" http://www-nrc.nokia.com/sw/draft-pstickler-tdl-00.html "The 'voc:' URI Scheme for Vocabulary Terms and Codes" http://www-nrc.nokia.com/sw/draft-pstickler-voc-00.html "The 'qname:' URI Scheme for XML Namespace Qualified Names" http://www-nrc.nokia.com/sw/draft-pstickler-qname-00.html "The 'xmlns:' URI Scheme for XML Namespace Declarations" http://www-nrc.nokia.com/sw/draft-pstickler-xmlns-00.html "The 'auth:' URI Scheme for Hierarchical Authority Identifiers" http://www-nrc.nokia.com/sw/draft-pstickler-auth-00.html Note that the URLs above are to unofficial copies of these drafts on the Nokia site, as they are not yet available (nor garunteed to be posted) on the IETF site. Any and all comments are most welcome. Regards, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 16 09:20:32 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08332 for ; Wed, 16 Jan 2002 09:20:28 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA22520; Wed, 16 Jan 2002 09:14:17 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5914 for URN-IETF@LISTS.NETSOL.COM; Wed, 16 Jan 2002 09:14:12 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA21657 for ; Wed, 16 Jan 2002 07:09:16 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04696; Wed, 16 Jan 2002 07:03:13 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200201161203.HAA04696@ietf.org> Date: Wed, 16 Jan 2002 07:03:13 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-ddds-toc-01.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Standard Author(s) : M. Mealling Filename : draft-ietf-urn-ddds-toc-01.txt Pages : 10 Date : 15-Jan-02 This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS) standard. The DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. This document along with RFC XXXX, RFC YYYY and RFC ZZZZ obsolete RFC 2168 [8] and RFC 2915 [6] as well as update RFC 2276 [5]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-toc-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-ddds-toc-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-ddds-toc-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020115095455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-ddds-toc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-ddds-toc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020115095455.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 16 09:21:53 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08359 for ; Wed, 16 Jan 2002 09:21:52 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA22554; Wed, 16 Jan 2002 09:16:06 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5918 for URN-IETF@LISTS.NETSOL.COM; Wed, 16 Jan 2002 09:16:03 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA21669 for ; Wed, 16 Jan 2002 07:09:20 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04728; Wed, 16 Jan 2002 07:03:17 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200201161203.HAA04728@ietf.org> Date: Wed, 16 Jan 2002 07:03:17 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-rfc2611bis-04.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URN Namespace Definition Mechanisms Author(s) : L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom Filename : draft-ietf-urn-rfc2611bis-04.txt Pages : 21 Date : 15-Jan-02 The URN WG has defined a syntax for Uniform Resource Names (URNs) [RFC2141], as well as some proposed mechanisms for their resolution and use in Internet applications ([RFCXXXX], [RFCYYYY]). The whole rests on the concept of individual 'namespaces' within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed ([RFC2288]), and this document lays out general definitions of and mechanisms for establishing URN 'namespaces'. This document obsoletes RFC2611. Discussion of this document should be directed to urn-ietf@ietf.org A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-rfc2611bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-rfc2611bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-rfc2611bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020115095506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-rfc2611bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-rfc2611bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020115095506.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 16 10:01:13 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10125 for ; Wed, 16 Jan 2002 10:01:13 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA23496; Wed, 16 Jan 2002 09:53:34 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6118 for URN-IETF@LISTS.NETSOL.COM; Wed, 16 Jan 2002 09:53:31 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA23303 for ; Wed, 16 Jan 2002 09:41:39 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g0GEVRij000590; Wed, 16 Jan 2002 09:31:27 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g0GEVR3Y000589; Wed, 16 Jan 2002 09:31:27 -0500 (EST) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Message-ID: <20020116093126.N29100@bailey.dscga.com> Date: Wed, 16 Jan 2002 09:31:26 -0500 Reply-To: Michael Mealling From: Michael Mealling Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: On Wed, Jan 16, 2002 at 02:41:06PM +0200, Patrick Stickler wrote: > The following internet drafts have been submitted to the IETF > for consideration: Hi Patrick, I assume you knew you were stiring up a hornets nest, right? ;-) > "An Extended Class Taxonomy for Uniform Resource Identifier Schemes" > http://www-nrc.nokia.com/sw/draft-pstickler-uri-taxonomy-00.html Being one of the people in the URI-IG that discussed the classical vs contemporay view (and an adherent of the contemporary view) I have to say that this way lies madness. Most of the people on the URI-IG were involved in the original discussions about URIs when we had such animals as URA, URMs, URCs, URAv2, etc. The thing that has become clear is that a given URI's characteristics have more to do with how it is used than what its scheme says. For example, Dan uses the http scheme for pretty much everything. For him the http scheme makes a pretty valid urn-like thing. Others don't use it that way so it doesn't have those semantics for them and thus isn't one. The one thing I do have a problem with is the inclusion of 'hrn:' along side 'urn:'. IMHO, since your 'hrn' proposal includes a domain-name it cannot be a URN because it is not persistent. The UUID version might but the domain-name based one isn't.... Beyond that the analysis is good from that point of view. The problem is getting agreement on it... > "The 'hrn:' URI Scheme for Hierarchical Resource Names" > http://www-nrc.nokia.com/sw/draft-pstickler-hrn-00.html As mentioned above, I think that this statement is erroneous: "This URI scheme is also a type of URN, as defined by RFC 2396, but is not a namespace of the 'urn:' URI scheme [5], because the 'urn:' scheme does not provide for hierarchical characteristics which are central to the semantics of this URI scheme. " The fact that there is a domain-name in there means that it violates the persistence requirement in RFC 2396. > "The 'uri:' URI Scheme for URI Reification" > http://www-nrc.nokia.com/sw/draft-pstickler-uri-00.html This is an interesting one but I think you should pick another scheme name. The one you picked will end up causing you to much argument over the name and none over the merits of the idea. The one question I have is: is reification so globally well understood that it means the same thing to everyone? I've been out of the RDF discussions but I seem to remember this being an issue at one point.... > "The 'tdl:' URI Scheme for Typed Data Literals" > http://www-nrc.nokia.com/sw/draft-pstickler-tdl-00.html What is the merit of this over the 'data:' scheme? > "The 'voc:' URI Scheme for Vocabulary Terms and Codes" > http://www-nrc.nokia.com/sw/draft-pstickler-voc-00.html I can't figure out what this scheme has that doesn't already exist in current schemes. It seems that this one definitely falls into the "a URI's semantics have more to do with how you use it than what the scheme has in it".... > "The 'qname:' URI Scheme for XML Namespace Qualified Names" > http://www-nrc.nokia.com/sw/draft-pstickler-qname-00.html Hmm.... I don't think a URI scheme can disclaim the URI Reference so the hash mark statement is false. hmm... This one also really strikes me as shortcutting RDF statements by putting them into the URI scheme itself. I.e. all of the examples are previously stated URI examples from other documents with an XML element name in front of it. Is it wise to be creating new URI schemes when a statement in RDF could do the same thing? > "The 'xmlns:' URI Scheme for XML Namespace Declarations" > http://www-nrc.nokia.com/sw/draft-pstickler-xmlns-00.html I thought we'd fixed that whole XML namespace thing? > "The 'auth:' URI Scheme for Hierarchical Authority Identifiers" > http://www-nrc.nokia.com/sw/draft-pstickler-auth-00.html What's the difference between this and an 'http:' scheme? > Any and all comments are most welcome. Sorry if it sounds like I was picking it apart. Its just that some of these ideas were discussed in other fora which is how we got to the "its how you use it, not the scheme name that's important" idea... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-urn-ietf@LISTS.NETSOL.COM Thu Jan 17 02:47:49 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09759 for ; Thu, 17 Jan 2002 02:47:49 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id CAA27286; Thu, 17 Jan 2002 02:44:24 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6378 for URN-IETF@LISTS.NETSOL.COM; Thu, 17 Jan 2002 02:44:01 -0500 Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id CAA27278 for ; Thu, 17 Jan 2002 02:43:59 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0H7c4k23392 for ; Thu, 17 Jan 2002 09:38:04 +0200 (EET) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jan 2002 09:37:56 +0200 Received: from [10.114.130.183] (tr-adsl-dhcp-130183.ntc.nokia.com [10.114.130.183]) by esebh01nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id DDBVYHGQ; Thu, 17 Jan 2002 09:37:55 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Thu, 17 Jan 2002 09:38:47 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <20020116093126.N29100@bailey.dscga.com> Content-Transfer-Encoding: 7bit On 2002-01-16 16:31, "ext Michael Mealling" wrote: > On Wed, Jan 16, 2002 at 02:41:06PM +0200, Patrick Stickler wrote: >> The following internet drafts have been submitted to the IETF >> for consideration: > > Hi Patrick, > I assume you knew you were stiring up a hornets nest, right? ;-) I'm quite aware that the issues that are addressed in my IDs are areas of strong debate, yes. >> "An Extended Class Taxonomy for Uniform Resource Identifier Schemes" >> http://www-nrc.nokia.com/sw/draft-pstickler-uri-taxonomy-00.html > > Being one of the people in the URI-IG that discussed the classical vs > contemporay view (and an adherent of the contemporary view) I have to > say > that this way lies madness. Perhaps you missed the part that said that it is compatible with either the classical or contemporary view? Let me stress it again, draft-pstickler-uri-taxonomy-00 is compatible with either the classical or contemporary view. If you read it without this understanding, I would encourage you to read it again. > Most of the people on the URI-IG were > involved > in the original discussions about URIs when we had such animals as > URA, URMs, URCs, URAv2, etc. The thing that has become clear is that > a given URI's characteristics have more to do with how it is used than > what its scheme says. Use and abuse are two different things. I assert that any use of a URI scheme contrary to the specified intended use is contrary to the very purpose of standards, and while research and advancement often need to bend the rules and try unconventional things, eventually, advancements and improvements need to be addressed in a standardized manner such that industry can build upon that knowledge in a consistent and reliable manner. > For example, Dan uses the http scheme for > pretty much everything. For him the http scheme makes a pretty valid > urn-like thing. Others don't use it that way so it doesn't have those > semantics for them and thus isn't one. IMO, a URI scheme defines, in addition to the syntax, a common semantics and basis for interpretation of instances of that scheme so that an application has at least half a clue what to do with such instances. Otherwise, let's all just use uuid: URIs and define the semantics in RDF. > The one thing I do have a problem with is the inclusion of 'hrn:' > along side 'urn:'. IMHO, since your 'hrn' proposal includes a > domain-name > it cannot be a URN because it is not persistent. The UUID version might > but the domain-name based one isn't.... You missed the essential point about my extended taxonomy and the definition of a URN -- that while a URN may embody within its representation the identity of the minting agent, it does not embody the identity of the resolution agent. URLs do both -- and in fact, the minting and resolution agents are the same. I suggest you re-read draft-pstickler-uri-taxonomy-00, particularly section 3. An 'hrn:' may include the web authority of the minting agent, and that is persistent, as that will never change. Unlike a URL, however, that is *not* the resolution authority -- which like all URNs -- remains undefined in the URI itself. The 'hrn:' scheme provides a consistent, open, non-centralized URN scheme that does not need a dedicated centralized authority for granting namespaces, but uses web authority as that namespace and thus is far better suited for the Web, not having the bottleneck of namespace registration preventing global and mass minting of URNs. Furthermore, the 'hrn:' URN scheme is a hierarchical URI scheme, which is highly desireable for many applications. By those two criteria, I consider the 'hrn:' URN scheme to be superior to the 'urn:' URN scheme -- though both are fully valid URN schemes in that neither refer to any resolution agency explicitly in their representation and are hence persistent in that regard. > Beyond that the analysis is good from that point of view. The problem is > getting agreement on it... Absolutely. Agreement about URI classes (or lack thereof) and URI semantics will be a long road, I think. But even though I'm coming late to this party, I think I've brought along some rather good music, and maybe we can all get into the same groove ;-) >> "The 'hrn:' URI Scheme for Hierarchical Resource Names" >> http://www-nrc.nokia.com/sw/draft-pstickler-hrn-00.html > > As mentioned above, I think that this statement is erroneous: > "This URI scheme is also a type of URN, as defined by RFC 2396, but is > not a > namespace of the 'urn:' URI scheme [5], because the 'urn:' scheme does > not provide for hierarchical characteristics which are central to the > semantics of this URI scheme. " > > The fact that there is a domain-name in there means that it violates > the persistence requirement in RFC 2396. But this persistence requirement has the rather narrow view that a web authority (domain name) only indicates a resolution agency, and that the URL-centric perspective perhaps precludes the broader role of a domain name representing only the minting agency, which even if that domain ceases to exist, remains historically valid and thus persistent -- within the scope of URN schemes which only attribute significance with regards to minting and not to resolution. >> "The 'uri:' URI Scheme for URI Reification" >> http://www-nrc.nokia.com/sw/draft-pstickler-uri-00.html > > This is an interesting one but I think you should pick another scheme > name. > The one you picked will end up causing you to much argument over the > name > and none over the merits of the idea. The one question I have is: is > reification so globally well understood that it means the same thing to > everyone? I've been out of the RDF discussions but I seem to remember > this being an issue at one point.... This URI scheme is specifically intended for use within RDF applications. And as for the name, it seems quite consistent with the URN/urn: convention ;-) After all, not all URNs are urn:'s. Likewise, not all URIs are uri:'s. But all urn:'s are URNs and all uri:'s are URIs. >> "The 'tdl:' URI Scheme for Typed Data Literals" >> http://www-nrc.nokia.com/sw/draft-pstickler-tdl-00.html > > What is the merit of this over the 'data:' scheme? Specific, constrained semantics. Furthermore, the 'data:' URI scheme requires that all datatypes be registered/defined as MIME types, which is an unnecessary overhead IMO for the kinds of datatypes in question. The 'tdl:' approach is that each datatype is denoted by a URI, and the pairing of datatype URI and lexical form uniquely identifies a member of the value space of the datatype. This is based on one proposal under consideration by the RDF Core Working Group for datatyping of literals in RDF. C.f. http://www-nrc.nokia.com/sw/TDL.html While the 'data:' URI scheme *could* be made to work for this application, it would be cumbersome. >> "The 'voc:' URI Scheme for Vocabulary Terms and Codes" >> http://www-nrc.nokia.com/sw/draft-pstickler-voc-00.html > > I can't figure out what this scheme has that doesn't already exist in > current schemes. It seems that this one definitely falls into the "a > URI's > semantics have more to do with how you use it than what the scheme has > in it".... Again, perhaps its significance is not seen because the distinction between URI classes as defined in draft-pstickler-uri-taxonomy-00 section 3 is not fully understood. The key point is that a 'voc:' URI does not resolve to "something else". It is a URP. Yes, you could define a similar URI using 'http:' but it would never be clear whether it should or should not resolve to anything, and if so, to what. This is the basis for the classical view that I openly admit to subscribing to. The URI scheme lets an application know what it should or should do with a given URI. Using 'http:' URLs for everything just leaves the application guessing. The syntactic similarities between 'voc:' and 'http:' are due to both of them being hierarchical URI schemes and utilizing web authorities -- but their semantics are *very* different. >> "The 'qname:' URI Scheme for XML Namespace Qualified Names" >> http://www-nrc.nokia.com/sw/draft-pstickler-qname-00.html > > Hmm.... I don't think a URI scheme can disclaim the URI Reference so the > hash mark statement is false. Under the currently defined URI Class taxonomy, consisting only of URLs and URNs, no -- but under my extended URI taxonomy, with URPs, it can. And actually, since the definition of a URI Reference is based on the *returned* media type from dereferencing a URI, and if a given URI scheme is never intended to be dereferenced, then it is IMO valid and reasonable to state that in such cases a URI Reference is simply undefined (cannot exist, or is vacuous). > hmm... This one also really strikes me > as shortcutting RDF statements by putting them into the URI scheme > itself. I.e. all of the examples are previously stated URI examples from > other documents with an XML element name in front of it. Is it wise to > be > creating new URI schemes when a statement in RDF could do the same > thing? This URI scheme has nothing to do with RDF/XML serialization. The utility of this URI scheme is to achieve intersection of knowledge in a 'tidy' RDF graph. "Constellations" of property/value pairs do not constitute equality in the eyes of RDF insofar as graph merging is concerned. A URI representation results in there being one and only one node in an RDF graph for each qualified name and allows one to make statements about that qualified name resource which are global to the knowledge base. >> "The 'xmlns:' URI Scheme for XML Namespace Declarations" >> http://www-nrc.nokia.com/sw/draft-pstickler-xmlns-00.html > > I thought we'd fixed that whole XML namespace thing? 1. XML Namespaces still remain problemmatic in several areas, but that is a totally disjunct discussion that I won't introduce here to this forum, especially since it is not relevant to the 'xmlns:' URI scheme itself. 2. The 'xmlns:' URI Scheme does not replace XML NS declarations in XML instances. As with 'qname:' it provides a consistent representation for NS declarations in an RDF knowledge base (or anywhere else such a representation is useful). >> "The 'auth:' URI Scheme for Hierarchical Authority Identifiers" >> http://www-nrc.nokia.com/sw/draft-pstickler-auth-00.html > > What's the difference between this and an 'http:' scheme? 1. It's a URV 2. It can be temporally qualified. 3. Its semantics are explicitly constrained to the representation of authoritative agents. >> Any and all comments are most welcome. > > Sorry if it sounds like I was picking it apart. No need for apologies, I wan't folks to pick them apart. That's how (a) they get better, and (b) how we achieve agreement. > Its just that some of > these > ideas were discussed in other fora which is how we got to the "its how > you use it, not the scheme name that's important" idea... As I said, I know I'm coming late into these discussions (or have missed them entirely ;-) but I sincerely feel that the contemporary view is missing something very important and essential -- perhaps not so essential for the Web, but definitly essential for the Semantic Web. Regards, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Thu Jan 17 03:34:10 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10185 for ; Thu, 17 Jan 2002 03:34:10 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id DAA27875; Thu, 17 Jan 2002 03:31:40 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6498 for URN-IETF@LISTS.NETSOL.COM; Thu, 17 Jan 2002 03:31:36 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id DAA27868 for ; Thu, 17 Jan 2002 03:31:34 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0H8PGu07673 for ; Thu, 17 Jan 2002 10:25:16 +0200 (EET) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jan 2002 10:25:29 +0200 Received: from [10.114.130.183] (tr-adsl-dhcp-130183.ntc.nokia.com [10.114.130.183]) by esebh01nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id DDBVYW57; Thu, 17 Jan 2002 10:25:29 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Thu, 17 Jan 2002 10:26:20 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Content-Transfer-Encoding: 7bit >> What is the merit of this over the 'data:' scheme? It's actually interesting (IMO) to note that a 'data:' URI is in fact a URV (and hence URP) as it is never dereferenced, but provides a complete, self-contained representation of a resource. It is a WYSIWIG URI. Thus the URV classification of 'data:' is far more accurate regarding its semantics and application than the current URL classification. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Thu Jan 17 03:58:46 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10350 for ; Thu, 17 Jan 2002 03:58:46 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id DAA28169; Thu, 17 Jan 2002 03:52:46 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6563 for URN-IETF@LISTS.NETSOL.COM; Thu, 17 Jan 2002 03:52:42 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id DAA28158 for ; Thu, 17 Jan 2002 03:52:40 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0H8kIu17584 for ; Thu, 17 Jan 2002 10:46:18 +0200 (EET) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jan 2002 10:46:32 +0200 Received: from [10.114.130.183] (tr-adsl-dhcp-130183.ntc.nokia.com [10.114.130.183]) by esebh01nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id DDBVY9X5; Thu, 17 Jan 2002 10:46:32 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Thu, 17 Jan 2002 10:47:24 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <20020116093126.N29100@bailey.dscga.com> Content-Transfer-Encoding: 7bit On 2002-01-16 16:31, "ext Michael Mealling" wrote: > ... The thing that has become clear is that > a given URI's characteristics have more to do with how it is used than > what its scheme says. I hardly consider that something that is "clear" or true. Take the simple example of the identity of a thing versus the identity of the representation of a thing, where that thing itself is not a digital resource, e.g. a car. The "use 'http:' URLs for everything' approach suggests that a given URL can be used both to denote the thing (the car) as well as be dereferenced to retrieve a representation of that thing (e.g. a photo, or technical specs, etc.) Yet, a SW application which is trying to "understand" a given statement such as Fred cannot tell whether Fred is the creator of the car itself or of the digital resource retrievable from the URL. Likewise, if the URL is intended only to be a URT -- i.e. to be a non-dereferencible identifier of a non-digital resource (just the car), an application has no way of knowing if a 404 error is a true error (i.e. it *should* resolve to "something") or just a side effect of the use of a URL as a URT. This degree of chaos in the interpretation of URIs is IMO completely unacceptable and will greatly hinder the advancement and deployment of useful SW applications. Far better would be Fred Picture of Fred's Car Toyota Fred's Car and an application knows, based on the defined semantics of 'http:' URLs that it should get "something" when it dereferences the URL and knows, based on the defined semantics of 'voc:' URTs that it should not dereference one but use it simply as a global identifier. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Thu Jan 17 04:08:21 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10407 for ; Thu, 17 Jan 2002 04:08:20 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id EAA28598; Thu, 17 Jan 2002 04:05:33 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6609 for URN-IETF@LISTS.NETSOL.COM; Thu, 17 Jan 2002 04:05:26 -0500 Received: from zark.ecotroph.net (64.83.37.226.dsl226-static-nova.cavtel.net [64.83.37.226]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id DAA28333 for ; Thu, 17 Jan 2002 03:55:24 -0500 (EST) Received: from thinkingcat.com ([::ffff:193.0.5.176]) (AUTH: LOGIN leslie, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zark.ecotroph.net with esmtp; Thu, 17 Jan 2002 03:19:04 -0500 X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.5-pt6 i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: leslie@LISTS.NETSOL.COM Message-ID: <3C468F85.EF0AC15@thinkingcat.com> Date: Thu, 17 Jan 2002 03:47:01 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Note that these are _not_ I-D's unless and until they _do_ appear in the IETF Internet-Draft repository. Patrick Stickler wrote: > Note that the URLs above are to unofficial copies of these > drafts on the Nokia site, as they are not yet available > (nor garunteed to be posted) on the IETF site. > > Any and all comments are most welcome. Leslie. -- ------------------------------------------------------------------- "An essential element of a successful journey is recognizing when you have arrived." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Thu Jan 17 12:51:26 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28187 for ; Thu, 17 Jan 2002 12:51:26 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA01097; Thu, 17 Jan 2002 12:47:28 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6959 for URN-IETF@LISTS.NETSOL.COM; Thu, 17 Jan 2002 12:46:34 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA01027 for ; Thu, 17 Jan 2002 12:33:13 -0500 (EST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id MAA15864; Thu, 17 Jan 2002 12:28:16 -0500 X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200201171728.MAA15864@markbaker.ca> Date: Thu, 17 Jan 2002 12:28:11 -0500 Reply-To: Mark Baker From: Mark Baker Subject: Content-Location is your friend To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: from "Patrick Stickler" at Jan 17, 2002 10:47:24 AM Content-Transfer-Encoding: 7bit Patrick, > The "use 'http:' URLs for everything' approach suggests > that a given URL can be used both to denote the thing > (the car) as well as be dereferenced to retrieve a > representation of that thing (e.g. a photo, or technical > specs, etc.) Right. > Yet, a SW application which is trying to "understand" > a given statement such as > > > Fred > > > cannot tell whether Fred is the creator of the car itself > or of the digital resource retrievable from the URL. That's not true. We've had this discussion before, and I've pointed out that your assertion above is about the *resource*, i.e. the car. If a particular representation of the car was created by somebody else, then that should be reflected in a different URI, and the relationship between http://foo.com/freds_car/ and this other URI should be authoritatively established with HTTP's Content-Location header. e.g. GET http://foo.com/freds_car/ HTTP/1.1 Host: foo.com Accept: image/gif response headers; HTTP/1.1 200 OK Content-Type: image/jpg Content-Location: http://foo.com/freds_car/image?format=jpg Then you could make assertions about that particular representation; Jane MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com From owner-urn-ietf@LISTS.NETSOL.COM Thu Jan 17 15:34:49 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11818 for ; Thu, 17 Jan 2002 15:34:49 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA01913; Thu, 17 Jan 2002 14:34:44 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7098 for URN-IETF@LISTS.NETSOL.COM; Thu, 17 Jan 2002 14:34:39 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA01706 for ; Thu, 17 Jan 2002 13:49:27 -0500 (EST) Received: from plato ([12.230.243.179]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020117184256.UMHE10199.rwcrmhc53.attbi.com@plato>; Thu, 17 Jan 2002 18:42:56 +0000 References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: <002e01c19f86$751c2f60$657ba8c0@c1457248a.sttls1.wa.home.com> Date: Thu, 17 Jan 2002 10:40:37 -0800 Reply-To: Seth Russell From: Seth Russell Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit From: "Patrick Stickler" I think you've done a great service to the SW in defining these new URI schema. They clearly define our names such that finally our RDF applications will know of what we speak:) Do you know of any nasty side effects of starting to use them immediately - i.e. will they break any known RDF parsers ? Seth Russell language: Semenglish URI seeAlso "http://www-nrc.nokia.com/sw/draft-pstickler-uri-taxonomy-00.html" , "http://lists.w3.org/Archives/Public/www-rdf-interest/2002Jan/0127.html" . From owner-urn-ietf@LISTS.NETSOL.COM Fri Jan 18 01:27:47 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23699 for ; Fri, 18 Jan 2002 01:27:47 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id BAA04858; Fri, 18 Jan 2002 01:22:05 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7395 for URN-IETF@LISTS.NETSOL.COM; Fri, 18 Jan 2002 01:21:48 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id BAA04846 for ; Fri, 18 Jan 2002 01:21:45 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0I6FTu20070 for ; Fri, 18 Jan 2002 08:15:29 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Jan 2002 08:15:43 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W234PT; Fri, 18 Jan 2002 08:15:39 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Fri, 18 Jan 2002 08:16:33 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <002e01c19f86$751c2f60$657ba8c0@c1457248a.sttls1.wa.home.com> Content-Transfer-Encoding: 7bit On 2002-01-17 20:40, "ext Seth Russell" wrote: > From: "Patrick Stickler" > > I think you've done a great service to the SW in defining these new URI > schema. They clearly define our names such that finally our RDF > applications will know of what we speak:) Blush... ;-) > Do you know of any nasty side effects of starting to use them immediately - > i.e. will they break any known RDF parsers ? I don't know of any URI schemes that will break any RDF parser, since URIs are expected to be fully opaque in the RDF graph. As to RDF applications that attempt to grok URIs for various purposes, I can't say. If they are "stupid" and presume that every URI is an 'http:' URI and barf when they fail to resolve, then of course, any of the URP schemes will choke such apps. But I think folks should be able to start using them immediately with few, if any, concerns of that sort. We are... ;-) Cheers, Patrick > Seth Russell > > language: Semenglish > URI > seeAlso > "http://www-nrc.nokia.com/sw/draft-pstickler-uri-taxonomy-00.html" , > > "http://lists.w3.org/Archives/Public/www-rdf-interest/2002Jan/0127.html" . > > -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Fri Jan 18 01:41:13 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23871 for ; Fri, 18 Jan 2002 01:41:12 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id BAA05091; Fri, 18 Jan 2002 01:37:14 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7445 for URN-IETF@LISTS.NETSOL.COM; Fri, 18 Jan 2002 01:37:07 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id BAA05084 for ; Fri, 18 Jan 2002 01:37:05 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0I6V6902411 for ; Fri, 18 Jan 2002 08:31:06 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Jan 2002 08:31:03 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W234V4; Fri, 18 Jan 2002 08:31:03 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Fri, 18 Jan 2002 08:31:57 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Content-Location is your friend To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <200201171728.MAA15864@markbaker.ca> Content-Transfer-Encoding: 7bit On 2002-01-17 19:28, "ext Mark Baker" wrote: > Patrick, > >> The "use 'http:' URLs for everything' approach suggests >> that a given URL can be used both to denote the thing >> (the car) as well as be dereferenced to retrieve a >> representation of that thing (e.g. a photo, or technical >> specs, etc.) > > Right. > >> Yet, a SW application which is trying to "understand" >> a given statement such as >> >> >> Fred >> >> >> cannot tell whether Fred is the creator of the car itself >> or of the digital resource retrievable from the URL. > > That's not true. We've had this discussion before, and I've pointed > out that your assertion above is about the *resource*, i.e. the car. > If a particular representation of the car was created by somebody else, > then that should be reflected in a different URI, I agree that if separate URIs are used to denote the non-digital resource and digital representations/expressions of that resource that what you say is true (though the argument that I was contesting about "multipurposed" URIs seems to be a common one). However, using a URL to denote a non-digital resource is IMO just plain bad practice. The point of the 'http:' URI scheme (and forgive me for telling all you other folks what that is, even those of you involved in writing the RFCs ;-) is to provide a URI that is meaningful to HTTP resolution, and HTTP resolution is intended to provide access to digital resources. The problem is that folks needing to talk about non-digital resources have been so 'http:' URL saturated that they started using them out of habit, or (fairly enough) not having much else to use, and then IMO folks started trying to re-define what URLs are for in order to justify this (mis)use. The distinction between URIs denoting accessible digital resources and URIs denoting either abstract concepts or non-digital resources is IMO crucial for the future of the SW. Again, it may not be crucial for the Web, but it is for the SW. > and the relationship > between http://foo.com/freds_car/ and this other URI should be > authoritatively established with HTTP's Content-Location header. A content header is not a digital-resource, it is part of the interchange protocol which describes to the recieving application what the content is -- how can you describe empty content? And this approach presumes that all that can be known about such a resource can be expressed in the content header. And it requires the explicit definition of "non-dereferencable" status for *every* such URI rather than globally for all instances of a particular URI scheme, or ideally for a URI class such as URP. Far better to be able to know that one has a URP and thereby know that the URI is non-dereferencable than have to define for *every* URP in existence an explicit header response. Yikes! What a massive overhead! This content header approach feels to me like a hack. Sorry. Regards, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Fri Jan 18 03:09:16 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03548 for ; Fri, 18 Jan 2002 03:09:16 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id DAA06037; Fri, 18 Jan 2002 03:05:11 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7638 for URN-IETF@LISTS.NETSOL.COM; Fri, 18 Jan 2002 03:05:03 -0500 Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id DAA06023 for ; Fri, 18 Jan 2002 03:05:01 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0I7x2k24144 for ; Fri, 18 Jan 2002 09:59:02 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Jan 2002 09:58:53 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W23WGT; Fri, 18 Jan 2002 09:58:30 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Fri, 18 Jan 2002 09:59:24 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Content-Location is your friend To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <200201180652.BAA23847@markbaker.ca> Content-Transfer-Encoding: 7bit On 2002-01-18 8:52, "ext Mark Baker" wrote: > whereas I would > prefer that *all* of these relationships were made explicit with the > mechanisms provided by the Semantic Web, and that the identifiers > themselves remain entirely opaque. Well, we could do that by simply using only UUIDs. But as I pointed out, having to define all of the common, shared semantics explicitly for every single identifier is IMO the way of madness. The whole point IMO of URI schemes is to be able to capture the common semantics and intended application of sets of identifiers in a consistent and efficient manner. Capturing common semantics in a formal taxonomy of URI schemes allows for all SW applications/layers to benefit, not just HTTP or applications built on HTTP protocols, but any SW application, standard, or methodology that is URI aware. HTTP is not the foundation/heart/soul of the SW. URIs are. The maximal point of intersection between SW applications should be URIs and the common semantics defined for URI schemes and the URI classes to which those schemes belong, and the taxonomy of schemes and classes should, IMO, be formal -- i.e. the classical view. Regards, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Fri Jan 18 09:40:32 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12766 for ; Fri, 18 Jan 2002 09:40:32 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA08009; Fri, 18 Jan 2002 09:37:31 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7896 for URN-IETF@LISTS.NETSOL.COM; Fri, 18 Jan 2002 09:37:14 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id BAA05693 for ; Fri, 18 Jan 2002 01:57:34 -0500 (EST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id BAA23847; Fri, 18 Jan 2002 01:52:50 -0500 X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200201180652.BAA23847@markbaker.ca> Date: Fri, 18 Jan 2002 01:52:50 -0500 Reply-To: Mark Baker From: Mark Baker Subject: Re: Content-Location is your friend To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: from "Patrick Stickler" at Jan 18, 2002 08:31:57 AM Content-Transfer-Encoding: 7bit > The problem is that folks needing to talk about non-digital resources > have been so 'http:' URL saturated that they started using them > out of habit, or (fairly enough) not having much else to use, and > then IMO folks started trying to re-define what URLs are for in > order to justify this (mis)use. Well I'm not going into that again, but at least we've boiled down your argument. 8-) > > and the relationship > > between http://foo.com/freds_car/ and this other URI should be > > authoritatively established with HTTP's Content-Location header. > > A content header is not a digital-resource, it is part of the > interchange protocol which describes to the recieving application > what the content is -- how can you describe empty content? It's an assertion, like any other on the Semantic Web, except in RFC 822 format rather than RDF. Anyhow, my general attitude towards your drafts are that it's a good idea to be able to know things about resources and the relationships between them. You appear to want to put at least some of this information into the URI scheme (e.g. HRNs, where the existence of one resource implies the existence of other resources), whereas I would prefer that *all* of these relationships were made explicit with the mechanisms provided by the Semantic Web, and that the identifiers themselves remain entirely opaque. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com From owner-urn-ietf@LISTS.NETSOL.COM Fri Jan 18 09:45:54 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13049 for ; Fri, 18 Jan 2002 09:45:53 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA08151; Fri, 18 Jan 2002 09:43:12 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7903 for URN-IETF@LISTS.NETSOL.COM; Fri, 18 Jan 2002 09:43:09 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA07856 for ; Fri, 18 Jan 2002 09:09:28 -0500 (EST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id JAA26188; Fri, 18 Jan 2002 09:04:44 -0500 X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200201181404.JAA26188@markbaker.ca> Date: Fri, 18 Jan 2002 09:04:44 -0500 Reply-To: Mark Baker From: Mark Baker Subject: Re: Content-Location is your friend To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: from "Patrick Stickler" at Jan 18, 2002 09:59:24 AM Content-Transfer-Encoding: 7bit > The whole point IMO of URI schemes is to be able to capture > the common semantics and intended application of sets of > identifiers in a consistent and efficient manner. That's true, but it doesn't mean that the only way to communicate that sort of information is with a new URI scheme. The most general model would be to assume an opaque URI scheme, and then build up from there, no? What should one do when they need to make these same kinds of assertions about an existing URI scheme that doesn't already support them (perhaps because it's opaque)? For example, what if the owner of example.org wants to assert that http://example.org/foo/bar implies the existence of http://example.org/foo and http://example.org/? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com From owner-urn-ietf@LISTS.NETSOL.COM Fri Jan 18 10:07:30 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13820 for ; Fri, 18 Jan 2002 10:07:30 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA08718; Fri, 18 Jan 2002 10:04:43 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8077 for URN-IETF@LISTS.NETSOL.COM; Fri, 18 Jan 2002 10:04:39 -0500 Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA08711 for ; Fri, 18 Jan 2002 10:04:37 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0IEwgk03641 for ; Fri, 18 Jan 2002 16:58:42 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Jan 2002 16:58:33 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W239RF; Fri, 18 Jan 2002 16:58:33 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Fri, 18 Jan 2002 16:59:26 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Content-Location is your friend To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <200201181404.JAA26188@markbaker.ca> Content-Transfer-Encoding: 7bit On 2002-01-18 16:04, "ext Mark Baker" wrote: >> The whole point IMO of URI schemes is to be able to capture >> the common semantics and intended application of sets of >> identifiers in a consistent and efficient manner. > > That's true, but it doesn't mean that the only way to communicate that > sort of information is with a new URI scheme. The most general model > would be to assume an opaque URI scheme, and then build up from there, > no? > > What should one do when they need to make these same kinds of assertions > about an existing URI scheme that doesn't already support them (perhaps > because it's opaque)? For example, what if the owner of example.org > wants to assert that http://example.org/foo/bar implies the existence of > http://example.org/foo and http://example.org/? But it does. Although it is rather implicit IMO in the definition of hierarchical URIs, the individual path components are distinct and hence can be referenced individually. Note that that does *not* mean that subpaths correlate to URIs, and this is the case also with 'hrn:' and 'voc:', only that one can deduce that such subpaths might be valid URIs and in the case of 'hrn:' and 'voc:' *if* they correlate to resources, there is a defined superordinate/subordinate relation. Obviously, though, it is difficult to rebake a cake, and if you put the wrong ingredients into it... cest la vie... ;-) Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Fri Jan 18 11:52:15 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18453 for ; Fri, 18 Jan 2002 11:52:15 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA09705; Fri, 18 Jan 2002 11:49:32 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8269 for URN-IETF@LISTS.NETSOL.COM; Fri, 18 Jan 2002 11:49:17 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA09592 for ; Fri, 18 Jan 2002 11:21:21 -0500 (EST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id LAA28919; Fri, 18 Jan 2002 11:16:39 -0500 X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200201181616.LAA28919@markbaker.ca> Date: Fri, 18 Jan 2002 11:16:38 -0500 Reply-To: Mark Baker From: Mark Baker Subject: Re: Content-Location is your friend To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: from "Patrick Stickler" at Jan 18, 2002 04:59:26 PM Content-Transfer-Encoding: 7bit > > What should one do when they need to make these same kinds of assertions > > about an existing URI scheme that doesn't already support them (perhaps > > because it's opaque)? For example, what if the owner of example.org > > wants to assert that http://example.org/foo/bar implies the existence of > > http://example.org/foo and http://example.org/? > > But it does. Although it is rather implicit IMO in the definition > of hierarchical URIs, the individual path components are distinct > and hence can be referenced individually. They can be referenced, but so can any local path. That's not the same as asserting that they actually identify a resource. Hierarchical naming does not in general imply the existence of resources elsewhere in that same hierarchy. If you think you've found some text to the contrary, I'd appreciate a pointer though, as I've been looking into the opacity qualities of RFC 2396 recently. The point here being that this assertion should be able to be made about any URI, not just ones using a particular URI scheme. So the most general model for this would be entirely opaque URIs, and explicit assertions made about them. > Note that that does *not* mean that subpaths correlate to URIs, > and this is the case also with 'hrn:' and 'voc:', only that one > can deduce that such subpaths might be valid URIs and in the case > of 'hrn:' and 'voc:' *if* they correlate to resources, there is > a defined superordinate/subordinate relation. Sorry, I don't follow. > Obviously, though, it is difficult to rebake a cake, and if you > put the wrong ingredients into it... cest la vie... ;-) That sounds like it would be funny, if I understood the context. 8-) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com From owner-urn-ietf@LISTS.NETSOL.COM Fri Jan 18 11:55:26 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18568 for ; Fri, 18 Jan 2002 11:55:26 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA09758; Fri, 18 Jan 2002 11:52:49 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8282 for URN-IETF@LISTS.NETSOL.COM; Fri, 18 Jan 2002 11:52:46 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA09751 for ; Fri, 18 Jan 2002 11:52:44 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0IGki908111 for ; Fri, 18 Jan 2002 18:46:44 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Jan 2002 18:46:41 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2PA3X; Fri, 18 Jan 2002 18:46:41 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Fri, 18 Jan 2002 18:47:34 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Content-Location is your friend To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <200201181616.LAA28919@markbaker.ca> Content-Transfer-Encoding: 7bit On 2002-01-18 18:16, "ext Mark Baker" wrote: >>> What should one do when they need to make these same kinds of assertions >>> about an existing URI scheme that doesn't already support them (perhaps >>> because it's opaque)? For example, what if the owner of example.org >>> wants to assert that http://example.org/foo/bar implies the existence of >>> http://example.org/foo and http://example.org/? >> >> But it does. Although it is rather implicit IMO in the definition >> of hierarchical URIs, the individual path components are distinct >> and hence can be referenced individually. > > They can be referenced, but so can any local path. That's not the same > as asserting that they actually identify a resource. > > Hierarchical naming does not in general imply the existence of resources > elsewhere in that same hierarchy. If you think you've found some text > to the contrary, I'd appreciate a pointer though, as I've been looking > into the opacity qualities of RFC 2396 recently. I agree. And never stated that such was the case. > The point here being that this assertion should be able to be made about > any URI, not just ones using a particular URI scheme. So the most > general model for this would be entirely opaque URIs, and explicit > assertions made about them. > >> Note that that does *not* mean that subpaths correlate to URIs, >> and this is the case also with 'hrn:' and 'voc:', only that one >> can deduce that such subpaths might be valid URIs and in the case >> of 'hrn:' and 'voc:' *if* they correlate to resources, there is >> a defined superordinate/subordinate relation. > > Sorry, I don't follow. Meaning exactly your argument above, that just because a hierarchical URI can be parsed into discrete subpaths doesn't mean that any of the subpaths denote a resource -- but if they do, there is additional semantics that can be inferred for an 'hrn:' and 'voc:' subpath that cannot be inferred for an 'http:' subpath (or any other hierarchical scheme I am aware of). Thus, there is functionality defined for 'hrn:'s and 'voc:'s that is not present in 'http:'s, all else being equal (which it isn't ;-) >> Obviously, though, it is difficult to rebake a cake, and if you >> put the wrong ingredients into it... cest la vie... ;-) > > That sounds like it would be funny, if I understood the context. > 8-) Meaning that if needed semantics are not defined for a given URI scheme from the get go, you can't (at least not easily) go back and add it. That's why alot of thought went into the recipes for 'hrn:' and 'voc:' ;-) (though they may still end up tasting bad to some folks ;-) Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Fri Jan 18 19:46:16 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01892 for ; Fri, 18 Jan 2002 19:46:16 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id TAA12202; Fri, 18 Jan 2002 19:41:17 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8580 for URN-IETF@LISTS.NETSOL.COM; Fri, 18 Jan 2002 19:40:47 -0500 Received: from mail006.syd.optusnet.com.au (mail006.syd.optusnet.com.au [203.2.75.230]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id TAA12190 for ; Fri, 18 Jan 2002 19:40:45 -0500 (EST) Received: from vlc.com.au (camax3-117.dialup.optusnet.com.au [198.142.118.117]) by mail006.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id g0J0YXm00451; Sat, 19 Jan 2002 11:34:33 +1100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Justin Couch Message-ID: <3C48BFC5.1060200@vlc.com.au> Date: Sat, 19 Jan 2002 11:37:25 +1100 Reply-To: Justin Couch From: Justin Couch Organization: The Virtual Light Company Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Patrick Stickler wrote: > As to RDF applications that attempt to grok URIs for various > purposes, I can't say. If they are "stupid" and presume that > every URI is an 'http:' URI and barf when they fail to resolve, > then of course, any of the URP schemes will choke such apps. > > But I think folks should be able to start using them immediately > with few, if any, concerns of that sort. For those using Java-based parsers, I'd be interested to know if my generalised URI resolver library handles these without modification. If not, what additions should I make to help that process out: http://www.vlc.com.au/urilib/ Latest updates are not in pre-compiled form, will need CVS for that. -- Justin Couch http://www.vlc.com.au/~justin/ Freelance Java Consultant http://www.yumetech.com/ Author, Java 3D FAQ Maintainer http://www.j3d.org/ ------------------------------------------------------------------- "Humanism is dead. Animals think, feel; so do machines now. Neither man nor woman is the measure of all things. Every organism processes data according to its domain, its environment; you, with all your brains, would be useless in a mouse's universe..." - Greg Bear, Slant ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Fri Jan 18 21:58:00 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04207 for ; Fri, 18 Jan 2002 21:58:00 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id VAA13048; Fri, 18 Jan 2002 21:50:59 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8709 for URN-IETF@LISTS.NETSOL.COM; Fri, 18 Jan 2002 21:50:51 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from polaris.childrenfirst.internal ([65.209.24.245]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id UAA12722 for ; Fri, 18 Jan 2002 20:11:25 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Re: Some recent Internet Drafts relating to URIs Thread-Index: AcGghSW6hIpLvepXTiyErutDWpzYZQAACj5A Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.netsol.com id UAA12723 Message-ID: <18B657EBE98B6946A3572E18C8DFC0C31B7EC9@polaris.childrenfirst.internal> Date: Fri, 18 Jan 2002 20:05:22 -0500 Reply-To: Bryan Schlegel From: Bryan Schlegel Subject: FW: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 8bit remove b@mycounsel.com or bryan@mycounsel.com....I am getting mail forwarded from old job. -----Original Message----- From: Justin Couch [mailto:justin@vlc.com.au] Sent: Friday, January 18, 2002 7:37 PM To: URN-IETF@LISTS.NETSOL.COM Subject: Re: Some recent Internet Drafts relating to URIs Patrick Stickler wrote: > As to RDF applications that attempt to grok URIs for various > purposes, I can't say. If they are "stupid" and presume that > every URI is an 'http:' URI and barf when they fail to resolve, > then of course, any of the URP schemes will choke such apps. > > But I think folks should be able to start using them immediately > with few, if any, concerns of that sort. For those using Java-based parsers, I'd be interested to know if my generalised URI resolver library handles these without modification. If not, what additions should I make to help that process out: http://www.vlc.com.au/urilib/ Latest updates are not in pre-compiled form, will need CVS for that. -- Justin Couch http://www.vlc.com.au/~justin/ Freelance Java Consultant http://www.yumetech.com/ Author, Java 3D FAQ Maintainer http://www.j3d.org/ ------------------------------------------------------------------- "Humanism is dead. Animals think, feel; so do machines now. Neither man nor woman is the measure of all things. Every organism processes data according to its domain, its environment; you, with all your brains, would be useless in a mouse's universe..." - Greg Bear, Slant ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Sat Jan 19 06:07:20 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18046 for ; Sat, 19 Jan 2002 06:07:20 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA15478; Sat, 19 Jan 2002 06:03:50 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9017 for URN-IETF@LISTS.NETSOL.COM; Sat, 19 Jan 2002 06:03:24 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA15471 for ; Sat, 19 Jan 2002 06:03:23 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0JAvM915940 for ; Sat, 19 Jan 2002 12:57:22 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 19 Jan 2002 12:57:20 +0200 Received: from [10.114.130.183] (tr-adsl-dhcp-130183.ntc.nokia.com [10.114.130.183]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0ZTW9XL; Sat, 19 Jan 2002 12:57:16 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Sat, 19 Jan 2002 12:58:07 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3C48BFC5.1060200@vlc.com.au> Content-Transfer-Encoding: 7bit On 2002-01-19 2:37, "ext Justin Couch" wrote: > Patrick Stickler wrote: > >> As to RDF applications that attempt to grok URIs for various >> purposes, I can't say. If they are "stupid" and presume that >> every URI is an 'http:' URI and barf when they fail to resolve, >> then of course, any of the URP schemes will choke such apps. >> >> But I think folks should be able to start using them immediately >> with few, if any, concerns of that sort. > > For those using Java-based parsers, I'd be interested to know if my > generalised URI resolver library handles these without modification. If > not, what additions should I make to help that process out: > > http://www.vlc.com.au/urilib/ > > Latest updates are not in pre-compiled form, will need CVS for that. I had a brief look, and my initial impression is that insofar as the 'hrn:' URN scheme is concerned, if you are treating URNs as fully opaque keys in a (possibly global) associative array (dictionary) then there should be no difference whatsoever from the treatment of 'urn:' URNs. I suspect that you are at least examining the URI scheme prefix to determine which class of URI they belong to (URL, URN, etc.) As for the other URP (URT/URV) schemes, the resolver is irrelevant, as URPs do not resolve to anything. If this sounds like I haven't fully understood the function of the urilib, please let me know and I'll have a closer look. Regards, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Sat Jan 19 06:10:06 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18067 for ; Sat, 19 Jan 2002 06:10:06 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA15537; Sat, 19 Jan 2002 06:06:51 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9028 for URN-IETF@LISTS.NETSOL.COM; Sat, 19 Jan 2002 06:06:48 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA15524 for ; Sat, 19 Jan 2002 06:06:46 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0JB0k916322 for ; Sat, 19 Jan 2002 13:00:46 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 19 Jan 2002 13:00:43 +0200 Received: from [10.114.130.183] (tr-adsl-dhcp-130183.ntc.nokia.com [10.114.130.183]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0ZTW96P; Sat, 19 Jan 2002 13:00:43 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Sat, 19 Jan 2002 13:01:38 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <18B657EBE98B6946A3572E18C8DFC0C31B7EC9@polaris.childrenfirst.internal> Content-Transfer-Encoding: 7bit It's important IMO to note that it is particularly such applications such as this urilib which require the classical view of URI Classification. If an application such as the urilib resolver cannot differentiate URIs based on scheme, and schemes based on classification as URL, URN, URP, etc. then it does not know if it should try to resolve a URI, and if so, how (by some protocol agent or some global mapping mechanism). Patrick On 2002-01-19 3:05, "ext Bryan Schlegel" wrote: > remove b@mycounsel.com or bryan@mycounsel.com....I am getting mail > forwarded from old job. > > -----Original Message----- > From: Justin Couch [mailto:justin@vlc.com.au] > Sent: Friday, January 18, 2002 7:37 PM > To: URN-IETF@LISTS.NETSOL.COM > Subject: Re: Some recent Internet Drafts relating to URIs > > > Patrick Stickler wrote: > >> As to RDF applications that attempt to grok URIs for various >> purposes, I can't say. If they are "stupid" and presume that >> every URI is an 'http:' URI and barf when they fail to resolve, >> then of course, any of the URP schemes will choke such apps. >> >> But I think folks should be able to start using them immediately >> with few, if any, concerns of that sort. > > For those using Java-based parsers, I'd be interested to know if my > generalised URI resolver library handles these without modification. If > not, what additions should I make to help that process out: > > http://www.vlc.com.au/urilib/ > > Latest updates are not in pre-compiled form, will need CVS for that. > > -- > Justin Couch http://www.vlc.com.au/~justin/ > Freelance Java Consultant http://www.yumetech.com/ > Author, Java 3D FAQ Maintainer http://www.j3d.org/ > ------------------------------------------------------------------- > "Humanism is dead. Animals think, feel; so do machines now. > Neither man nor woman is the measure of all things. Every organism > processes data according to its domain, its environment; you, with > all your brains, would be useless in a mouse's universe..." > - Greg Bear, Slant > ------------------------------------------------------------------- > -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Sat Jan 19 06:22:49 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18159 for ; Sat, 19 Jan 2002 06:22:49 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA15882; Sat, 19 Jan 2002 06:19:34 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9117 for URN-IETF@LISTS.NETSOL.COM; Sat, 19 Jan 2002 06:19:27 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA15875 for ; Sat, 19 Jan 2002 06:19:26 -0500 (EST) Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0JBD8u10124 for ; Sat, 19 Jan 2002 13:13:08 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 19 Jan 2002 13:13:23 +0200 Received: from [10.114.130.183] (tr-adsl-dhcp-130183.ntc.nokia.com [10.114.130.183]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0ZTW0G5; Sat, 19 Jan 2002 13:13:22 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Sat, 19 Jan 2002 13:14:17 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Content-Location is your friend To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Content-Transfer-Encoding: 7bit On 2002-01-19 10:45, "ext Patrick Stickler" wrote: > If there is consistent, uniform intersection of semantics for > all instances of a URI scheme, then define that semantics within > the scope of the URI Scheme definition -- and in fact I assert > that that is precisely why we have URI Schemes. And if there is consistent, uniform intersection of semantics for a set of URI schemes, then define that semantics within the scope of a URI class (URN, URL, URP, URT, URV, etc.) -- and I assert that this is precisely why we need the classical view of URI classification and that the taxonomy of URI Classes must be formal, so that the knowledge about the semantics of URI schemes and URIs can be expressed and available to applications in a maximally efficient manner. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Sat Jan 19 07:10:48 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18425 for ; Sat, 19 Jan 2002 07:10:48 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA16983; Sat, 19 Jan 2002 07:07:36 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9379 for URN-IETF@LISTS.NETSOL.COM; Sat, 19 Jan 2002 07:07:31 -0500 Received: from mail015.syd.optusnet.com.au (mail015.syd.optusnet.com.au [203.2.75.178]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA16976 for ; Sat, 19 Jan 2002 07:07:29 -0500 (EST) Received: from vlc.com.au (camax3-147.dialup.optusnet.com.au [198.142.118.147]) by mail015.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id g0JC1Lh19123; Sat, 19 Jan 2002 23:01:21 +1100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Justin Couch Message-ID: <3C4960BB.8070408@vlc.com.au> Date: Sat, 19 Jan 2002 23:04:12 +1100 Reply-To: Justin Couch From: Justin Couch Organization: The Virtual Light Company Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Patrick Stickler wrote: > If an application such as the urilib resolver cannot differentiate > URIs based on scheme, and schemes based on classification as URL, URN, > URP, etc. then it does not know if it should try to resolve a URI, and > if so, how (by some protocol agent or some global mapping mechanism). Internally the urilib does not care, it resolves everything according to the URI DDDS mechanisms. It is only if you use the derived classes of URL and URN do you notice at the application level any difference. The URN class is coded to look for the "urn:" prefix, so that would be of no use to you. When using the URL class, it will strip the URI and look for the protocol part and then dynamically load an appropriate protocol handler for it. However, you don't need to do that either as you can perform the standard transformations such as I2C, I2Ns etc. Scheme and protocol are treated theoretically the same in this case. If you created a URL object using "hrn:" as the start of the string, I think it would pass through the system unnoticed (assuming you wrote the right resource-resolver implementation). Alternatively, you could extend the URI base class to create a HRN class and do any extra bits yourself. I'm not sure how well that would fare, but first pass approximation should not be that hard to do. Maybe some of the trickier semantics internally would be where you fall over. eg, does the HRN have the equivalent to a L2N transformation? -- Justin Couch http://www.vlc.com.au/~justin/ Freelance Java Consultant http://www.yumetech.com/ Author, Java 3D FAQ Maintainer http://www.j3d.org/ ------------------------------------------------------------------- "Humanism is dead. Animals think, feel; so do machines now. Neither man nor woman is the measure of all things. Every organism processes data according to its domain, its environment; you, with all your brains, would be useless in a mouse's universe..." - Greg Bear, Slant ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Sun Jan 20 11:39:36 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12861 for ; Sun, 20 Jan 2002 11:39:36 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA23657; Sun, 20 Jan 2002 11:35:06 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9910 for URN-IETF@LISTS.NETSOL.COM; Sun, 20 Jan 2002 11:34:39 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA23646 for ; Sun, 20 Jan 2002 11:34:37 -0500 (EST) Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0KGSHu28464 for ; Sun, 20 Jan 2002 18:28:17 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 20 Jan 2002 18:28:34 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2QA6K; Sun, 20 Jan 2002 18:28:33 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Sun, 20 Jan 2002 18:29:31 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3C4960BB.8070408@vlc.com.au> Content-Transfer-Encoding: 7bit On 2002-01-19 14:04, "ext Justin Couch" wrote: > ... The > URN class is coded to look for the "urn:" prefix, But not all URNs are 'urn:'s. 'hrn:'s are also URNs. > ... If you created a URL object > using "hrn:" But you wouldn't do that, since an 'hrn:' is not a URL, it is a URN. Furthermore, it seems much more efficient and reliable to define the class of the scheme rather than manually define the class of each URI instance. I.e., define once that 'http:' URIs are URLs and 'urn:' URIs are URLs, and interpret all URIs based on those formal classifications. Eh? Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Sun Jan 20 13:17:28 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14540 for ; Sun, 20 Jan 2002 13:17:28 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA24447; Sun, 20 Jan 2002 13:13:59 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10047 for URN-IETF@LISTS.NETSOL.COM; Sun, 20 Jan 2002 13:13:54 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA24218 for ; Sun, 20 Jan 2002 12:10:35 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g0KH0Tij007439; Sun, 20 Jan 2002 12:00:29 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g0KH0SRW007438; Sun, 20 Jan 2002 12:00:28 -0500 (EST) References: <3C4960BB.8070408@vlc.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Message-ID: <20020120120028.B4756@bailey.dscga.com> Date: Sun, 20 Jan 2002 12:00:28 -0500 Reply-To: Michael Mealling From: Michael Mealling Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: On Sun, Jan 20, 2002 at 06:29:31PM +0200, Patrick Stickler wrote: > On 2002-01-19 14:04, "ext Justin Couch" wrote: > > ... The > > URN class is coded to look for the "urn:" prefix, > > But not all URNs are 'urn:'s. > > 'hrn:'s are also URNs. We tried that route and after almost 10 years never got any agreement on it. Both sides had perfectly valid points so we wasted _years_ of time on arguments that in the end wouldn't have changed much anyway... > > ... If you created a URL object > > using "hrn:" > > But you wouldn't do that, since an 'hrn:' is not a URL, it > is a URN. And I disagree. A 'URN' is just one URI scheme and trying to get everyone to agree that there's more to it than that just wont' fly. I tried arguing that for a long time and in the end I realized it just wasn't worth the effort. The best thing you can and will get is to simply say that there are URIs and that each scheme has its own semantics and anything beyond that is application specific. IMNSHO, I think you'll have a better chance putting these semantics into RDF than you ever will getting them as standard parts of the URI definitions.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-urn-ietf@LISTS.NETSOL.COM Sun Jan 20 13:21:35 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14608 for ; Sun, 20 Jan 2002 13:21:35 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA24550; Sun, 20 Jan 2002 13:18:55 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10075 for URN-IETF@LISTS.NETSOL.COM; Sun, 20 Jan 2002 13:18:52 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA24543 for ; Sun, 20 Jan 2002 13:18:46 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0KICRu07783 for ; Sun, 20 Jan 2002 20:12:27 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 20 Jan 2002 20:12:43 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2QCNR; Sun, 20 Jan 2002 20:12:43 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3094402421_474862" Approved-By: Patrick Stickler Message-ID: Date: Sun, 20 Jan 2002 20:13:38 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <20020120120028.B4756@bailey.dscga.com> > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3094402421_474862 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit On 2002-01-20 19:00, "ext Michael Mealling" wrote: > On Sun, Jan 20, 2002 at 06:29:31PM +0200, Patrick Stickler wrote: >> On 2002-01-19 14:04, "ext Justin Couch" wrote: >>> ... The >>> URN class is coded to look for the "urn:" prefix, >> >> But not all URNs are 'urn:'s. >> >> 'hrn:'s are also URNs. > > We tried that route and after almost 10 years never got any agreement on it. > Both sides had perfectly valid points so we wasted _years_ of time on > arguments that in the end wouldn't have changed much anyway... Interesting.... so you propose a monopoly on indirect identifier schemes? What about folks who need or want a hierarchical URN scheme? What about folks who do not wish to reserve a 'urn:' namespace because the space they want to use will be transient -- but none the less in need of global uniqueness. What about ... surely I don't need to enumerate all of the obvious cases where 'uri:' doesn't do the job... Sorry that I wasn't present for those ten long years of discussion. I don't agree, though, with your asserted conclusions. >>> ... If you created a URL object >>> using "hrn:" >> >> But you wouldn't do that, since an 'hrn:' is not a URL, it >> is a URN. > > And I disagree. A 'URN' is just one URI scheme and trying to get everyone > to agree that there's more to it than that just wont' fly. I tried arguing > that for a long time and in the end I realized it just wasn't worth the > effort. Let's please keep the terminology straight. 'URN' is a URI Class, not a scheme. If you wish to assert that there is one and only one URN scheme, namely 'urn:', fine, but they are *not* the same thing. Whether you subscribe to the classical or contemporary view of whether URI classes should be formal or not, the classes still have definition, and when we speak of URI, URL, URN, etc. we speak of classes, not schemes. And when I assert that 'hrn:' is a URN scheme, that assertion is valid, even per the contemporary view. Whether or not some application should *know* that it is a URN and ascribe some common shared semantics of URN'ness to it, or whether it should take it in isolation of any classification, is a separate issue. I.e. the only difference between the classical and contemporary views is whether URI classifications are formal or not, not whether those URI classes have definition (possibly only informal). > The best thing you can and will get is to simply say that there are URIs > and that each scheme has its own semantics and anything beyond that is > application specific. IMNSHO, I think you'll have a better chance putting > these semantics into RDF than you ever will getting them as standard parts > of the URI definitions.... I intend to express them in RDF, and applications which choose the classical view of URI classification (that such classifications are formal) may use such RDF schemas as the mechanism for formal application of such common semantics. E.g. see attachment... Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com --B_3094402421_474862 Content-type: application/octet-stream; name="URI.rdf" Content-disposition: attachment Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIj8+DQoNCjwhLS0NCg0KICBSREYgU2NoZW1hIGZvciBFeHRl bmRlZCBUYXhvbm9teSBvZiBVUkkgQ2xhc3Nlcw0KDQogIEF1dGhvcjogUGF0cmljayBTdGlj a2xlciAocGF0cmljay5zdGlja2xlckBub2tpYS5jb20pDQoNCiAgQ29weXJpZ2h0IChDKSAy MDAxLTIwMDIgTm9raWENCg0KICBDLmYuIGh0dHA6Ly9pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtcHN0aWNrbGVyLXVyaS10YXhvbm9teS0wMC50eHQNCg0KICBMYXN0IG1vZGlm aWVkOiAkRGF0ZTogMjAwMi8wMS8yMCAxODowNjo1NSAkDQoNCi0tPg0KDQo8IURPQ1RZUEUg dXJpZGVmIFsNCiAgPCFFTlRJVFkgcmRmICAgICJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAy LzIyLXJkZi1zeW50YXgtbnMjIj4NCiAgPCFFTlRJVFkgcmRmcyAgICJodHRwOi8vd3d3Lncz Lm9yZy8yMDAwLzAxL3JkZi1zY2hlbWEjIj4NCiAgPCFFTlRJVFkgdXJpICAgICJ2b2M6Ly9u b2tpYS5jb20vVVJJLVRheG9ub215LTEuMC8iPg0KXT4NCg0KPHJkZjpSREYNCiAgIHhtbG5z OnJkZiAgICAgID0iJnJkZjsiDQogICB4bWxuczpyZGZzICAgICA9IiZyZGZzOyINCiAgIHht bG5zICAgICAgICAgID0iJnVyaTsiDQo+DQoNCjwhLS09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0tLT4NCg0KPHJk ZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiZ1cmk7VVJJIi8+DQoNCjxyZGY6RGVzY3JpcHRp b24gcmRmOmFib3V0PSImdXJpO1VSTCI+DQogICA8cmRmczpzdWJDbGFzc09mIHJkZjpyZXNv dXJjZT0iJnVyaTtVUkkiLz4NCjwvcmRmOkRlc2NyaXB0aW9uPg0KDQo8cmRmOkRlc2NyaXB0 aW9uIHJkZjphYm91dD0iJnVyaTtVUk4iPg0KICAgPHJkZnM6c3ViQ2xhc3NPZiByZGY6cmVz b3VyY2U9IiZ1cmk7VVJJIi8+DQo8L3JkZjpEZXNjcmlwdGlvbj4NCg0KPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiZ1cmk7VVJQIj4NCiAgIDxyZGZzOnN1YkNsYXNzT2YgcmRmOnJl c291cmNlPSImdXJpO1VSSSIvPg0KPC9yZGY6RGVzY3JpcHRpb24+DQoNCjxyZGY6RGVzY3Jp cHRpb24gcmRmOmFib3V0PSImdXJpO1VSVCI+DQogICA8cmRmczpzdWJDbGFzc09mIHJkZjpy ZXNvdXJjZT0iJnVyaTtVUlAiLz4NCjwvcmRmOkRlc2NyaXB0aW9uPg0KDQo8cmRmOkRlc2Ny aXB0aW9uIHJkZjphYm91dD0iJnVyaTtVUlYiPg0KICAgPHJkZnM6c3ViQ2xhc3NPZiByZGY6 cmVzb3VyY2U9IiZ1cmk7VVJQIi8+DQo8L3JkZjpEZXNjcmlwdGlvbj4NCg0KPCEtLT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PS0tPg0KDQo8dXJpOlVSTCByZGY6YWJvdXQ9Imh0dHA6Ii8+DQo8dXJpOlVSTCBy ZGY6YWJvdXQ9Im1haWx0bzoiLz4NCjx1cmk6VVJOIHJkZjphYm91dD0idXJuOiIvPg0KPHVy aTpVUk4gcmRmOmFib3V0PSJocm46Ii8+DQo8dXJpOlVSVCByZGY6YWJvdXQ9InZvYzoiLz4N Cjx1cmk6VVJWIHJkZjphYm91dD0iYXV0aDoiLz4NCjx1cmk6VVJWIHJkZjphYm91dD0idGRs OiIvPg0KPCEtLSAuLi4gLS0+DQoNCjwhLS0gYWxvbmcgd2l0aCBhbGwga2luZHMgb2Ygc3Rh dGVtZW50cyBhYm91dCB3aGVyZSBlYWNoIGNsYXNzDQogICAgIGFuZCBzY2hlbWUgaXMgZGVm aW5lZCwgY29tbWVudHMsIGNyb3NzIHJlZnMsIGV0Yy4gZXRjLiAtLT4NCg0KPC9yZGY6UkRG Pg0KDQo= --B_3094402421_474862-- From owner-urn-ietf@LISTS.NETSOL.COM Sun Jan 20 13:35:33 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14695 for ; Sun, 20 Jan 2002 13:35:32 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA24940; Sun, 20 Jan 2002 13:33:03 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10162 for URN-IETF@LISTS.NETSOL.COM; Sun, 20 Jan 2002 13:33:00 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA24933 for ; Sun, 20 Jan 2002 13:32:58 -0500 (EST) Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0KIQdu09346 for ; Sun, 20 Jan 2002 20:26:39 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 20 Jan 2002 20:26:56 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2QCXT; Sun, 20 Jan 2002 20:26:55 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Sun, 20 Jan 2002 20:27:52 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Content-Transfer-Encoding: 7bit On 2002-01-20 20:13, "ext Patrick Stickler" wrote: > ... surely I don't need to enumerate all of the > obvious cases where 'uri:' doesn't do the job... Sorry. Typo. that should have been 'urn:'. ^ Hopefully it was obvious ;-) Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Sun Jan 20 13:57:55 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14836 for ; Sun, 20 Jan 2002 13:57:54 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA25744; Sun, 20 Jan 2002 13:53:40 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10319 for URN-IETF@LISTS.NETSOL.COM; Sun, 20 Jan 2002 13:53:32 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA25417 for ; Sun, 20 Jan 2002 13:41:13 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g0KIV8ij007566; Sun, 20 Jan 2002 13:31:08 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g0KIV7bQ007565; Sun, 20 Jan 2002 13:31:07 -0500 (EST) References: <20020120120028.B4756@bailey.dscga.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Message-ID: <20020120133107.D4756@bailey.dscga.com> Date: Sun, 20 Jan 2002 13:31:07 -0500 Reply-To: Michael Mealling From: Michael Mealling Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: On Sun, Jan 20, 2002 at 08:13:38PM +0200, Patrick Stickler wrote: > On 2002-01-20 19:00, "ext Michael Mealling" wrote: > > On Sun, Jan 20, 2002 at 06:29:31PM +0200, Patrick Stickler wrote: > >> On 2002-01-19 14:04, "ext Justin Couch" wrote: > >>> ... The > >>> URN class is coded to look for the "urn:" prefix, > >> > >> But not all URNs are 'urn:'s. > >> > >> 'hrn:'s are also URNs. > > > > We tried that route and after almost 10 years never got any agreement on it. > > Both sides had perfectly valid points so we wasted _years_ of time on > > arguments that in the end wouldn't have changed much anyway... > > Interesting.... so you propose a monopoly on indirect identifier schemes? No. I'm saying that attempting to assert something like that as universal isn't very productive... > What about folks who need or want a hierarchical URN scheme? Fine. Specify a new URI scheme and say those are its semantics. But don't call it a URN since that name is already taken for a different scheme. > What about folks who do not wish to reserve a 'urn:' namespace because the > space they want to use will be transient -- but none the less in need of > global uniqueness. What about ... surely I don't need to enumerate all of the > obvious cases where 'uri:' doesn't do the job... 'uri:'? There is a method specified in RFC 2717 for how to get a new URI scheme. The document uses the term 'URL' but that's a historical artifact and not indicative that it excludes particular schemes. > Sorry that I wasn't present for those ten long years of discussion. Don't be. It wasn't fun. But please don't ignore it.... > I don't agree, though, with your asserted conclusions. Fine. I don't agree with some of yours. The question is: how are we going to get along? > >>> ... If you created a URL object > >>> using "hrn:" > >> > >> But you wouldn't do that, since an 'hrn:' is not a URL, it > >> is a URN. > > > > And I disagree. A 'URN' is just one URI scheme and trying to get everyone > > to agree that there's more to it than that just wont' fly. I tried arguing > > that for a long time and in the end I realized it just wasn't worth the > > effort. > > Let's please keep the terminology straight. 'URN' is a URI Class, not a > scheme. If you wish to assert that there is one and only one URN scheme, > namely 'urn:', fine, but they are *not* the same thing. Nope... Sorry. I have to use the terminology that we've been using for the past several years that a lot of us have finally agreed upon. If you want to introduce new terms that are specific to your application then fine. But please don't re-use old ones. Its to confusing and raises to many hackles.... > Whether you subscribe to the classical or contemporary view of whether > URI classes should be formal or not, the classes still have definition, > and when we speak of URI, URL, URN, etc. we speak of classes, not schemes. Nope. These groups have spent _considerable_ amount of time coming to the contemporary conclusion. Most importantly the IETF has been trying to deprecate the use of the term 'URL' ever since '93. > And when I assert that 'hrn:' is a URN scheme, that assertion is valid, For you it might be. But you're asserting _vastly_ different definitions for your terms than most here would... > even per the contemporary view. Whether or not some application should > *know* that it is a URN and ascribe some common shared semantics of URN'ness > to it, or whether it should take it in isolation of any classification, > is a separate issue. > > I.e. the only difference between the classical and contemporary views > is whether URI classifications are formal or not, not whether those > URI classes have definition (possibly only informal). Ok, then we weren't clear. I think what the group meant to say is that talking about URI classes _in general_ is a useless endeavor and _in general_ shouldn't be done.... > > The best thing you can and will get is to simply say that there are URIs > > and that each scheme has its own semantics and anything beyond that is > > application specific. IMNSHO, I think you'll have a better chance putting > > these semantics into RDF than you ever will getting them as standard parts > > of the URI definitions.... > > I intend to express them in RDF, and applications which choose the classical > view of URI classification (that such classifications are formal) may use > such RDF schemas as the mechanism for formal application of such > common semantics. Fine. But don't start out by attempting to redefine how URIs work. Do that redefinition in RDF using RDF's rule. Its kind of like me redefining now RDF works so I can do what I want to do. It might work for me but it causes all sorts of interoperability problems... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-urn-ietf@LISTS.NETSOL.COM Mon Jan 21 00:53:07 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22978 for ; Mon, 21 Jan 2002 00:53:07 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id AAA28420; Mon, 21 Jan 2002 00:48:56 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10591 for URN-IETF@LISTS.NETSOL.COM; Mon, 21 Jan 2002 00:47:20 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id AAA28413 for ; Mon, 21 Jan 2002 00:47:14 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0L5fF908217 for ; Mon, 21 Jan 2002 07:41:15 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 21 Jan 2002 07:41:11 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2QVQQ; Mon, 21 Jan 2002 07:41:11 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Mon, 21 Jan 2002 07:42:09 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <20020120133311.E4756@bailey.dscga.com> Content-Transfer-Encoding: 7bit On 2002-01-20 20:33, "ext Michael Mealling" wrote: > On Sun, Jan 20, 2002 at 08:27:52PM +0200, Patrick Stickler wrote: >> On 2002-01-20 20:13, "ext Patrick Stickler" >> wrote: >> >>> ... surely I don't need to enumerate all of the >>> obvious cases where 'uri:' doesn't do the job... >> >> Sorry. Typo. that should have been 'urn:'. >> >> Hopefully it was obvious ;-) > > Nope. But now it makes more sense. The 'urn:' scheme never suggests > that it is the only uri scheme that has 'naming' semantics. There > can be others if you need additional semantics. But don't call those > other name-like URI schemes URNs. Its just not productive and it confuses > the hell out of people... > > -MM I've actually found few to none that have been confused by my calling an 'hrn:' a URN and who didn't follow what was meant by URL/URN/URP/URT/URV. It seems that most of the folks who have a problem with the classical view are also those who are highly http: URI centric (i.e. use 'http:' URIs for everything). Those who feel that 'http:' URIs are URLs and should be expected to resolve to "something" and not be used to denote abstract or non-digital resources seem to have no problem whatsoever with the distinction between URL, URN, etc. Finally, it may be that all this has been hashed out in considerable detail in the past (perhaps there are some position summaries in the W3C or IETF archives?) but the fact that class identifiers such as URL, URN, etc. "won't die" suggests that the contemporary view does not reflect the needs of the web community at large. The thought has frequently crossed my mind that, while the Web may get along with the contemporary view, the Semantic Web will not (or not as well). Ultimately, the needs of applications will decide the classicial vs. contemporary issue (and I don't consider it closed) and there are now emerging applications that will benefit from a formal, explicit classification of URI schemes. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Jan 21 01:59:45 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23520 for ; Mon, 21 Jan 2002 01:59:45 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id BAA29151; Mon, 21 Jan 2002 01:55:41 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10742 for URN-IETF@LISTS.NETSOL.COM; Mon, 21 Jan 2002 01:55:36 -0500 Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id BAA29144 for ; Mon, 21 Jan 2002 01:55:34 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0L6nfk02444 for ; Mon, 21 Jan 2002 08:49:41 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 21 Jan 2002 08:49:32 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2QYGT; Mon, 21 Jan 2002 08:49:32 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Mon, 21 Jan 2002 08:50:29 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: Some recent Internet Drafts relating to URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <20020120133107.D4756@bailey.dscga.com> Content-Transfer-Encoding: 7bit On 2002-01-20 20:31, "ext Michael Mealling" wrote: > On Sun, Jan 20, 2002 at 08:13:38PM +0200, Patrick Stickler wrote: >> On 2002-01-20 19:00, "ext Michael Mealling" wrote: >>> On Sun, Jan 20, 2002 at 06:29:31PM +0200, Patrick Stickler wrote: >>>> On 2002-01-19 14:04, "ext Justin Couch" wrote: >>>>> ... The >>>>> URN class is coded to look for the "urn:" prefix, >>>> >>>> But not all URNs are 'urn:'s. >>>> >>>> 'hrn:'s are also URNs. >>> >>> We tried that route and after almost 10 years never got any agreement on it. >>> Both sides had perfectly valid points so we wasted _years_ of time on >>> arguments that in the end wouldn't have changed much anyway... >> >> Interesting.... so you propose a monopoly on indirect identifier schemes? > > No. I'm saying that attempting to assert something like that as > universal isn't very productive... But your trying to assert the opposite. That there is no such thing as a URN other than a 'urn:'. The characteristics of a URN scheme are clear enough. If a URI scheme has those characteristics then it is fair to call it a URN. Honestly, I find the contemporary view very "backwards" in terms of "contemporary" object oriented engineering which attempts to capture and reuse generalities wherever possible. Having no formal taxonomy of URI schemes imposes extra burden on applications which must interpret URIs. >> What about folks who need or want a hierarchical URN scheme? > > Fine. Specify a new URI scheme and say those are its semantics. But > don't call it a URN since that name is already taken for a different > scheme. I disagree. A "clarification" from the W3C does not constitute the dissolution of the relevant RFC's IMO, and unless you can justify that the use of a formal taxonomy has a negative impact to *applications* I see no valid reason for precluding its use. > Fine. I don't agree with some of yours. The question is: how are > we going to get along? Well, I don't intend to win my point by argument (alone). My present work in the are of metadata driven systems and semantic web applications (which make use of URPs, URTs, URVs, and of course, URNs and URLs) should sufficiently demonstrate the need and validity of a formal URI class taxonomy. All in good time... >>>>> ... If you created a URL object >>>>> using "hrn:" >>>> >>>> But you wouldn't do that, since an 'hrn:' is not a URL, it >>>> is a URN. >>> >>> And I disagree. A 'URN' is just one URI scheme and trying to get everyone >>> to agree that there's more to it than that just wont' fly. I tried arguing >>> that for a long time and in the end I realized it just wasn't worth the >>> effort. >> >> Let's please keep the terminology straight. 'URN' is a URI Class, not a >> scheme. If you wish to assert that there is one and only one URN scheme, >> namely 'urn:', fine, but they are *not* the same thing. Sorry, but I don't get that from *any* of the official publications of either the W3C or IETF (and I've been reading carefully). Perhaps you or a group of folks in some discussion list say so, but from what I can tell, URN and 'urn:' are not considered the same thing. It is true that the recent W3C clarification appears to assert that there is one and only one URN scheme, 'urn:', and from that, one may consider the two synonymous -- but only if one agrees with such an assertion (I certainly don't, and it appears that alot of other folks also don't). > Nope... Sorry. I have to use the terminology that we've been using > for the past several years that a lot of us have finally agreed upon. > If you want to introduce new terms that are specific to your application > then fine. But please don't re-use old ones. Its to confusing and raises > to many hackles.... I'm not using any new terms. I'm using the terms as they have been defined. I *am* of course, using them as defined by the classical view, and even to a certain extent compatable with my understanding of the contemporary view. It seems that there is a third view -- the "absolutist view" ;-) which does not recognize the terms URN or URL at all. >> Whether you subscribe to the classical or contemporary view of whether >> URI classes should be formal or not, the classes still have definition, >> and when we speak of URI, URL, URN, etc. we speak of classes, not schemes. > > Nope. These groups have spent _considerable_ amount of time coming to the > contemporary conclusion. Most importantly the IETF has been trying to > deprecate the use of the term 'URL' ever since '93. It may need to try harder ;-) IMO, and with all due respect to all of the participants of those long and painful debates that I seem to have missed, the contemporary view has emerged simply because (a) even though URNs were defined, there was no standard resolution solution and those that needed them were a very small minority of web users and (b) 'http:' URLs were highly visible and taken by the majority of web users to be synonymous with URIs and when folks needed URIs for non-digital or abstract resources, they used 'http:' URIs and the (bad) practice became so prolific, that folks threw up their hands and said "since 'http:' URIs are no longer consistently URLs, let's forget about the distinction -- missing the whole point that (1) the distinction is valuable and valid, and (2) bad practice, however prolific, should not be a basis for architectural design. Yes, I admit, "them's fightin words" and apologies in advance for all insult and injury that may result from them, but I think there is much more than a grain of truth there... and there's more... When XML Namespaces came along, folks understandably but inadvisably began using 'http:' URIs for namespaces -- with the interpretation and expectation (not specified in the XML NS spec) that the namespace URI resolve to "something" giving us hacks like RDDL which (albeit a useful solution for general cataloging of model related information) misses the whole point that a namespace does not equate to either a vocabulary or a single schema but is nothing but punctuation; and further served to encourage the mis-interpretation of namespace URIs. Had there been valid URT schemes in place when XML NS came, and had they been used in the XML NS examples, we would have avoided *alot* of confusion and the differences between namespace, vocabulary, content model, and schema would be clearer and more widely understood. Now, all of that mess was still something the Web could live with, but... The SW, however, changes things quite a bit. Now there is a significant need for globally unique identifiers denoting abstract concepts and the difference between a 'thing' and some representation of that 'thing' that is web accessible becomes acute. And of course, we've needed URT schemes all along for our DTDs, XML Schemas, RDF Schemas, etc. And applications neeed to know if an identifier denotes a web resource or some other, non-accessible (non-digital or abstract) resource, and that requires knowledge about the URI schemes. Furthermore, online publishing and media distribution is beginning to come of age, and the need for URNs is growing with it. Surely folks at the IETF have noted a increase in the demand for registered 'urn:' namespaces? Hence the recent streamlining? Thus there is growing need for applications to be able to organize and interpret URIs according to scheme specific semantics, and there are numerous schemes with major, functional intersections of semantics which would beg for a taxonomy of schemes, thus the classical view is becoming a necessity. (and just so folks know where I'm coming from, in addition to being active in the RDF and SW communities, and a member of the W3C RDF Core WG, I am also a member of both the Metadata and Identifiers working groups of the Open eBook Forum, the leading standard for ePublications, and also am the chief architect of Nokia's documentation and digital resource management solutions, managing several million pages of complex technical, procedural, and user documentation, so my views are based on long, hard experience, and are not just so much arm waving and armchair philosophising) All in all, I think that the contemporary view does not serve the needs of the emerging semantic web and that if 'http:' (mis)use is set aside, out of the picture, it becomes very hard to justify the disposal of the URL, URN, etc. distinctions, and the extended classes URP, URT, and URV reflect distinctions needed by the SW and KM communities for some time. Oh, and by the way... ;-) ;-) ;-) >> And when I assert that 'hrn:' is a URN scheme, that assertion is valid, > > For you it might be. But you're asserting _vastly_ different definitions > for your terms than most here would... And where precisely is "here"? Planet Earth? IETF? W3C? The URN list? The URI list? >> even per the contemporary view. Whether or not some application should >> *know* that it is a URN and ascribe some common shared semantics of URN'ness >> to it, or whether it should take it in isolation of any classification, >> is a separate issue. >> >> I.e. the only difference between the classical and contemporary views >> is whether URI classifications are formal or not, not whether those >> URI classes have definition (possibly only informal). > > Ok, then we weren't clear. I think what the group meant to say is that > talking about URI classes _in general_ is a useless endeavor and _in general_ > shouldn't be done.... What's interesting is that, while I've always understood the W3C clarification as being a clarification of the *views* -- a tour of the classical and contemporary views and what each one asserts or presumes -- the folks who were involved in writing it seem to think that it rather is a mandate for adoption of the contemporary view. I.e. that the interpretation and understanding of the document requires alot of reading between the lines or familiarity with the discussions of the past. Furthermore, I consider the choice of terms "contemporary" and "classical" as politically biased, such that if one does not subscribe to the "contemporary" view, one is behind the times and not "with it". It says nothing specific to application designers about what the two views mean -- apart from a single mention of the word "formal", which implies that per the contemporary view, URI classes have no formal definition that an application could make use of. If not for implementors, then who is the document intended for? And, contrary to what you assert above, it does not IMO say that it is either unproductive nor unadvisable or incorrect to speak in terms of URI classes or to assign classifications to URI schems. As far as "clarifications" go, it's not very clear. >>> The best thing you can and will get is to simply say that there are URIs >>> and that each scheme has its own semantics and anything beyond that is >>> application specific. IMNSHO, I think you'll have a better chance putting >>> these semantics into RDF than you ever will getting them as standard parts >>> of the URI definitions.... >> >> I intend to express them in RDF, and applications which choose the classical >> view of URI classification (that such classifications are formal) may use >> such RDF schemas as the mechanism for formal application of such >> common semantics. > > Fine. But don't start out by attempting to redefine how URIs work. And why the heck not? If ever there was something in need of standardized definition, it is URI classification. As I've said before, URIs are the heart and soul of both the Web and the Semantic Web, so while it is clearly a challenge, we do need to agree about them. And my extended taxonomy is based on foundational RFCs which, as far as I am aware, are still valid and authoritative (to the extent that any RFC is authoritative). Again, if the IETF or W3C wishes to "kill" URI classes once and for all, then rewrite the RFCs or publish new ones that supercede and deprecate the current ones. "Clarifications" that have multiple interpretations just won't do. As for me, whether or not it remains a standard, I will continue to hold the classicial view and utilize formal definitions of URI classes, and avoid misusing 'http:' URLs as URNs or URTs. Regards, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Jan 21 02:37:55 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02154 for ; Mon, 21 Jan 2002 02:37:55 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id CAA29751; Mon, 21 Jan 2002 02:35:07 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10869 for URN-IETF@LISTS.NETSOL.COM; Mon, 21 Jan 2002 02:34:54 -0500 Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id CAA29736 for ; Mon, 21 Jan 2002 02:34:52 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0L7T0k15387 for ; Mon, 21 Jan 2002 09:29:00 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 21 Jan 2002 09:28:50 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2QZ7Y; Mon, 21 Jan 2002 09:28:50 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Mon, 21 Jan 2002 09:29:47 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <000e01c1a22c$f1aea5a0$06560150@localhost> Content-Transfer-Encoding: 7bit On 2002-01-21 5:37, "ext Sean B. Palmer" wrote: > Hi Patrick, > > Sorry for taking so long to go through your recent URx publications; > here are some fairly innane questions, and some general comments. > > My first Q is about the hierarchial URN scheme. Michael pointed out > that they can have domain names as authority components, which isn't > all that persistent. UUIDs would be alright, but they're fairly > difficult to generate. The other option is a tag-esque "domain,date" > component - which brings me to the question: how does "hrn:" differ > from "tag:"? As I pointed out in an earlier response, the use of the web authority does not make an 'hrn:' non-persistent, as the web authority in an 'hrn:' represents only the minting authority, and not the resolution authority. In an 'http:' URL, a web authority is both, and thus if it changes or becomes inactive, the resolution authority becomes invalid and thus persistence is impacted. 'hrn:' URNs do not have that problem, even though web authorities may be used, because the web authority remains historically valid and even if it becomes inactive, that has no impact on the persistent validity of the 'hrn:' URN. See section 3 of draft-pstickler-uri-taxonomy-00 regarding these distinctions. The benefit of allowing a web authority as the minting authority is that it provides a far less centralized method of "namespace" than 'urn:' NIDs or purchasing of URIs from NID owners (e.g. DOI, ISBN, etc.). With 'hrn:'s, anyone can mint a mnemonic URN based on a web authority, or a non-mnemonic (or partially mnemonic) URN based on a UUID easily and without fear of collision. And those URNs can be hierarchically defined to boot. 'hrn:' = "URN Power to the People" ;-) > I presume that the hierarchial aspect is what you're > after, although I'm not sure what the relationship between the > segments is. Hierarchy was one desired characteristic. Minimially-centrallized minting was another (i.e. based on any web authority, not having to register a namespace or pay some agency that has a namespace). Per above. > Why not use ":" as a hierarchial segment delimiter in > "tag:"? Because there already is a standard syntax for hierarchical URIs and many APIs and libraries exist for parsing such hierarchical URIs into their components. Why introduce another hierarchical syntax if the present standard does the job? > Note that "tag:" was going to be registered as a URI, and URN > NID. I understand that. But it appears to me that it is only the contemporary view that forces this redundancy. You should be able to register it simply as a URI with a classification of URN. Or, you can register it as an NID of the 'urn:' scheme. Why do both? Having both 'xxx:foo' and 'urn:xxx:foo' is sure to result in alot of needless overhead. > Next Q: I can't work out what "voc:" is for, if anything. The draft > states: "This provides a more robust and safe treatment of unqualified > names than the 'online:' or 'genid:' treatments employed by most RDF > systems to date.", so it sounds as if they're meant to be replacements > for anonymous nodes... but the structure of the URIs suggests > otherwise. The use of 'voc:' in RDF for providing non-collisive identifiers for local (not anonymous) resources is very much a fringe use. The 'voc:' URT scheme is intended for vocabularies. See the examples in the I-D. That should clarify its intended usage. In short, for the URIs of all element and attribute names of all XML content models, for the URIs of all resource names of all RDF schemas, for the URIs of all controlled vocabularies and taxonomies such as ISO language and country codes, TGN geographic names, etc. etc. I.e. for all abstract identifiers. I think that the 'voc:' URT scheme is the most important of all of the newly proposed schemes, and has the widest application. > I've also been wondering about the taxonomy in general. A lot of > people will tell you that an HTTP URI is just as good a persistent > identifier as any URN - it's the social contract that matters, and > HTTP URIS are widely deployed. The URN/URL/URP taxonomy feels rather > artificial to me, and I fear that creators of new schemes will have to > beg to you as the arbiter of where a new scheme belongs. I agree that before such a taxonomy would reach the maturity of a standard that it would need more precise definition. I think though that the criteria distinguishing the proposed classes is fairly straightforward. If your URI scheme denotes a point of access, it is a URL. If it denotes an indirect access key, it is a URN, if it does not resolve (is self contained) it is a URP. I.e.: URL direct resolution URN indirect resolution URP no resolution > [BTW, I'm not > sure I would have chosen the acronym "URP". Every time I write it, I > feel like excusing myself afterwards]. It does seem to give a few folks indigestion ;-) > For example, you've listed ESL as a URV. I can see the motivation > behind that, and I would agree - if not for the fact that ESL could > easily have been submitted as a URN NID. But why? Is the primary and fundamental purpose of an 'esl:' URI to denote some other web resource independent of its location? > At the moment, I am one of > those who feel that the boundary between URP and URN is not all that > solid. [In fact, I wonder why there isn't a "uri-x:" alternative of > "urn:urn-x:".] > > I'm not sure what the utility of the "qname:" scheme is. In fact, many > of the drafts are lacking in describing the utility of the schemes > themselves. Whilst this seems to be common practise, it's something > that I battle against. All new schemes should have a detailed space > describing their purpose and motivation, because it obviates arguments > later on. If you could prepare a summary of the aims of each scheme, > that would be rather useful. All of the schemes have specific utility but I tried to avoid being too specific with regards to all possible applications, keeping each I-D focused on the essential technical details regarding the URI scheme in a generic fashion that would be as future-flexible as possible. I am actually working on a more descriptive account of where/how each is used, which, if I get it done in time, I will likely submit for the SW track at WWW12. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Jan 21 09:51:34 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11094 for ; Mon, 21 Jan 2002 09:51:34 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA01839; Mon, 21 Jan 2002 09:48:58 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11123 for URN-IETF@LISTS.NETSOL.COM; Mon, 21 Jan 2002 09:48:51 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA01832 for ; Mon, 21 Jan 2002 09:48:49 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0LEgUu19676 for ; Mon, 21 Jan 2002 16:42:30 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 21 Jan 2002 16:42:43 +0200 Received: from [172.22.43.211] (trd043-211.research.nokia.com [172.22.43.211]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0ZTZZB3; Mon, 21 Jan 2002 16:42:42 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Mon, 21 Jan 2002 16:43:40 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Content-Transfer-Encoding: 7bit From: Patrick Stickler Date: Mon, 21 Jan 2002 16:06:03 +0200 To: "ext Daniel R. Tobias" Subject: Re: URx Questions On 2002-01-21 15:38, "ext Daniel R. Tobias" wrote: >> Having both 'xxx:foo' and 'urn:xxx:foo' is sure to result in >> alot of needless overhead. > > True... I've noticed a current trend in Internet drafts to try to get > both forms of each new scheme... this is rather confusing, and leaves > me wondering which I'm supposed to use if I decide I want to use one > of those new schemes to give unique names to things. Do I use the > "urn:" prefix if I want them to ultimately resolve to some Web > resource, and leave it out if I don't expect such resolution to ever > happen? But what if I change my mind later? Does that mean I end up > with two different URIs for the same thing? Exactly. It should be clearly stated that there should either be a URI scheme or a 'urn:' Namespace, but not both, otherwise one must equate all pairs of URIs from either. > But even if I want them > to resolve, how wold they... none of these new schemes seem to be > giving the slightest clue as to how they would actually be resolved > as URNs. > > Actually, in general, that seems to be the biggest problem with URNs; > they're a good concept in theory, but in practice even after years of > discussion nobody seems to really know how they're going to be made > resolvable. Well, resolution of URNs has always been contextual. Work is finally reaching maturity on a global, distributed mapping table that would bind URNs to URLs and would allow any client, anywhere to retrieve resources by URN as easily as URLs using a system similar (actually based on) the DNS system. But one can always provide localized resolution solutions. Nokia uses URNs to identify all managed digital resources, and retrieval is based on configuration for a given site or client, as to which registry or archive the resource is accesable. This system has been in use now for a couple of years, and so when folks say that all URNs must be urn:s, I have to laugh. C.f. http://www-nrc.nokia.com/sw/Metia.zip > Some of these new proposed schemes offer namespaces > whereby anybody can create names at will, but in the absence of any > registration system that puts them all in a big database, and with > explicit definitions to the effect that the use of domain names to > identify the minting authority does not imply that this authority is > actually reachable currently at that address, there simply does not > seem to be any reasonable mechanism by which a user agent might try > to resolve them into a resource. > > By those standards, URPs may make more sense, since they are > explicitly defined not to resolve into anything. We still need URNs. We need a way to name things without having to worry about where those things might be stored or managed. Such as the name of a book or image or soundtrack, which may in fact get stored in many locations for various reasons, but is still the very same "thing". I see three parts to URN usage: 1. Minting of the URN, which must be globally and temporally unique. 2. Describing the resource in terms of the URN (optional really) such as ownership, encoding, language, etc. 3. Mapping the URN to a URL or other means of retrieval, for a given environment (which may be global) Most URN schemes (ISBN, DOI, etc.) force you to pay for all three services, when one may not need all of them -- and most such schemes put a focus on high persistence, security, and quality which, while very important for large publishers, are not as critical for most folks and also price such services way beyond the reach of most folks (just price a few DOIs and ISBNs, very expensive). So my goals with the 'hrn:' URN scheme is to provide a reliable and cheap way for folks to mint URNs and then address the description and mapping issues seperately. There already are several description solutions available, including open source such as the Open Archives Initiative. And since it is not too hard or expensive to get Web or FTP space, the mapping and retrieval is also easy to arrange -- especially if the description solution is used to define the mapping, by simply including a property such as 'location' which is a URL. So, whether or not the global resolution solutions planned for URNs happen or not, we can still use URNs very effectively and they are very much needed. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Jan 21 09:57:49 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11342 for ; Mon, 21 Jan 2002 09:57:49 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA01913; Mon, 21 Jan 2002 09:53:55 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11120 for URN-IETF@LISTS.NETSOL.COM; Mon, 21 Jan 2002 09:53:48 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from polaris.childrenfirst.internal ([65.209.24.245]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA01301 for ; Mon, 21 Jan 2002 07:06:01 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Re: URx Questions Thread-Index: AcGiUUWghSsQnXIRR52xZ+7DbUq2GgAIdrLg Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.netsol.com id HAA01302 Message-ID: <18B657EBE98B6946A3572E18C8DFC0C31B7ED5@polaris.childrenfirst.internal> Date: Mon, 21 Jan 2002 06:59:59 -0500 Reply-To: Bryan Schlegel From: Bryan Schlegel Subject: FW: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 8bit how do i get off this list? -----Original Message----- From: Patrick Stickler [mailto:patrick.stickler@nokia.com] Sent: Monday, January 21, 2002 2:30 AM To: URN-IETF@LISTS.NETSOL.COM Subject: Re: URx Questions On 2002-01-21 5:37, "ext Sean B. Palmer" wrote: > Hi Patrick, > > Sorry for taking so long to go through your recent URx publications; > here are some fairly innane questions, and some general comments. > > My first Q is about the hierarchial URN scheme. Michael pointed out > that they can have domain names as authority components, which isn't > all that persistent. UUIDs would be alright, but they're fairly > difficult to generate. The other option is a tag-esque "domain,date" > component - which brings me to the question: how does "hrn:" differ > from "tag:"? As I pointed out in an earlier response, the use of the web authority does not make an 'hrn:' non-persistent, as the web authority in an 'hrn:' represents only the minting authority, and not the resolution authority. In an 'http:' URL, a web authority is both, and thus if it changes or becomes inactive, the resolution authority becomes invalid and thus persistence is impacted. 'hrn:' URNs do not have that problem, even though web authorities may be used, because the web authority remains historically valid and even if it becomes inactive, that has no impact on the persistent validity of the 'hrn:' URN. See section 3 of draft-pstickler-uri-taxonomy-00 regarding these distinctions. The benefit of allowing a web authority as the minting authority is that it provides a far less centralized method of "namespace" than 'urn:' NIDs or purchasing of URIs from NID owners (e.g. DOI, ISBN, etc.). With 'hrn:'s, anyone can mint a mnemonic URN based on a web authority, or a non-mnemonic (or partially mnemonic) URN based on a UUID easily and without fear of collision. And those URNs can be hierarchically defined to boot. 'hrn:' = "URN Power to the People" ;-) > I presume that the hierarchial aspect is what you're > after, although I'm not sure what the relationship between the > segments is. Hierarchy was one desired characteristic. Minimially-centrallized minting was another (i.e. based on any web authority, not having to register a namespace or pay some agency that has a namespace). Per above. > Why not use ":" as a hierarchial segment delimiter in > "tag:"? Because there already is a standard syntax for hierarchical URIs and many APIs and libraries exist for parsing such hierarchical URIs into their components. Why introduce another hierarchical syntax if the present standard does the job? > Note that "tag:" was going to be registered as a URI, and URN > NID. I understand that. But it appears to me that it is only the contemporary view that forces this redundancy. You should be able to register it simply as a URI with a classification of URN. Or, you can register it as an NID of the 'urn:' scheme. Why do both? Having both 'xxx:foo' and 'urn:xxx:foo' is sure to result in alot of needless overhead. > Next Q: I can't work out what "voc:" is for, if anything. The draft > states: "This provides a more robust and safe treatment of unqualified > names than the 'online:' or 'genid:' treatments employed by most RDF > systems to date.", so it sounds as if they're meant to be replacements > for anonymous nodes... but the structure of the URIs suggests > otherwise. The use of 'voc:' in RDF for providing non-collisive identifiers for local (not anonymous) resources is very much a fringe use. The 'voc:' URT scheme is intended for vocabularies. See the examples in the I-D. That should clarify its intended usage. In short, for the URIs of all element and attribute names of all XML content models, for the URIs of all resource names of all RDF schemas, for the URIs of all controlled vocabularies and taxonomies such as ISO language and country codes, TGN geographic names, etc. etc. I.e. for all abstract identifiers. I think that the 'voc:' URT scheme is the most important of all of the newly proposed schemes, and has the widest application. > I've also been wondering about the taxonomy in general. A lot of > people will tell you that an HTTP URI is just as good a persistent > identifier as any URN - it's the social contract that matters, and > HTTP URIS are widely deployed. The URN/URL/URP taxonomy feels rather > artificial to me, and I fear that creators of new schemes will have to > beg to you as the arbiter of where a new scheme belongs. I agree that before such a taxonomy would reach the maturity of a standard that it would need more precise definition. I think though that the criteria distinguishing the proposed classes is fairly straightforward. If your URI scheme denotes a point of access, it is a URL. If it denotes an indirect access key, it is a URN, if it does not resolve (is self contained) it is a URP. I.e.: URL direct resolution URN indirect resolution URP no resolution > [BTW, I'm not > sure I would have chosen the acronym "URP". Every time I write it, I > feel like excusing myself afterwards]. It does seem to give a few folks indigestion ;-) > For example, you've listed ESL as a URV. I can see the motivation > behind that, and I would agree - if not for the fact that ESL could > easily have been submitted as a URN NID. But why? Is the primary and fundamental purpose of an 'esl:' URI to denote some other web resource independent of its location? > At the moment, I am one of > those who feel that the boundary between URP and URN is not all that > solid. [In fact, I wonder why there isn't a "uri-x:" alternative of > "urn:urn-x:".] > > I'm not sure what the utility of the "qname:" scheme is. In fact, many > of the drafts are lacking in describing the utility of the schemes > themselves. Whilst this seems to be common practise, it's something > that I battle against. All new schemes should have a detailed space > describing their purpose and motivation, because it obviates arguments > later on. If you could prepare a summary of the aims of each scheme, > that would be rather useful. All of the schemes have specific utility but I tried to avoid being too specific with regards to all possible applications, keeping each I-D focused on the essential technical details regarding the URI scheme in a generic fashion that would be as future-flexible as possible. I am actually working on a more descriptive account of where/how each is used, which, if I get it done in time, I will likely submit for the SW track at WWW12. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Jan 21 10:19:42 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12124 for ; Mon, 21 Jan 2002 10:19:42 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA02651; Mon, 21 Jan 2002 10:16:57 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11318 for URN-IETF@LISTS.NETSOL.COM; Mon, 21 Jan 2002 10:16:46 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA02644 for ; Mon, 21 Jan 2002 10:16:44 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0LFAj906424 for ; Mon, 21 Jan 2002 17:10:45 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 21 Jan 2002 17:10:41 +0200 Received: from [172.22.43.211] (trd043-211.research.nokia.com [172.22.43.211]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0ZTZ5G8; Mon, 21 Jan 2002 17:10:40 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Mon, 21 Jan 2002 17:11:37 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <20020121092536.F7674@bailey.dscga.com> Content-Transfer-Encoding: 7bit On 2002-01-21 16:25, "ext Michael Mealling" wrote: >> By those standards, URPs may make more sense, since they are >> explicitly defined not to resolve into anything. > > That _is_ one of the requirements of URNs. They were _never_ required > to be resolvable in the first place. Many of the currently registered > URNs will never have a resolution method because non will exist. > So the lament that "nobody seems to really know how they're going to be > made resolvable" is missing most of the point of URNs to begin with. > But maybe that was our fault as well... There is, I feel, a significant difference between might not resolve and must not resolve. It is true that a resource denoted by a URN may never have a digital representation instantiated at any given location, but that doesn't make such a URN the equivalent of a URP. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Jan 21 11:07:51 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14193 for ; Mon, 21 Jan 2002 11:07:50 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA03509; Mon, 21 Jan 2002 11:04:44 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11512 for URN-IETF@LISTS.NETSOL.COM; Mon, 21 Jan 2002 11:04:31 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from email8.net ([65.112.130.132]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA03436 for ; Mon, 21 Jan 2002 10:52:51 -0500 (EST) Received: from [65.112.130.130] (HELO dan) by email8.net (CommuniGate Pro SMTP 3.4.3) with ESMTP id 1499328; Mon, 21 Jan 2002 10:47:20 -0500 MIME-Version: 1.0 Priority: normal References: <20020121092536.F7674@bailey.dscga.com> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Message-ID: <3C4BF194.10433.3C89E7B7@localhost> Date: Mon, 21 Jan 2002 10:46:44 -0500 Reply-To: "Daniel R. Tobias" From: "Daniel R. Tobias" Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Content-Transfer-Encoding: 7BIT On 21 Jan 2002 at 17:11, Patrick Stickler wrote: > There is, I feel, a significant difference between might not resolve > and must not resolve. It is true that a resource denoted by a URN may > never have a digital representation instantiated at any given location, > but that doesn't make such a URN the equivalent of a URP. But, to play "devil's advocate" for the contemporary paradigm (after my earlier arguments in favor of a more elaborate taxonomy), "never" is a very long time... things tend to change, sometimes in unpredictable ways, but their names don't always change accordingly -- look at the Los Angeles Lakers and Utah Jazz, whose team names made more sense when they were the Minneapolis Lakers and New Orleans Jazz. Thus, when somebody assigns a name in a particular URI scheme to something based on his assessment of whether or not that "something" ever will be resolvable on the Internet, this assessment may well be contradicted by later events, leading to a need for a kludged-up method of resolving URIs of a form that were supposed to be defined to be unresolvable, or contrariwise, to the continued use of URIs to things no longer resolvable that use schemes that indicate supposedly resolvable resources, because they've embedded themselves as identifiers in some context where they can't easily be changed. -- Dan Dan's Web Tips: http://www.dantobias.com/webtips/ From owner-urn-ietf@LISTS.NETSOL.COM Mon Jan 21 11:32:48 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15793 for ; Mon, 21 Jan 2002 11:32:48 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA04000; Mon, 21 Jan 2002 11:30:16 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11622 for URN-IETF@LISTS.NETSOL.COM; Mon, 21 Jan 2002 11:30:13 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA03992 for ; Mon, 21 Jan 2002 11:30:11 -0500 (EST) Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0LGNqu28114 for ; Mon, 21 Jan 2002 18:23:52 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 21 Jan 2002 18:24:09 +0200 Received: from [172.22.43.211] ([172.22.43.211]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2RQM0; Mon, 21 Jan 2002 18:24:07 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Mon, 21 Jan 2002 18:25:05 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3C4BF194.10433.3C89E7B7@localhost> Content-Transfer-Encoding: 7bit On 2002-01-21 17:46, "ext Daniel R. Tobias" wrote: > On 21 Jan 2002 at 17:11, Patrick Stickler wrote: > >> There is, I feel, a significant difference between might not resolve >> and must not resolve. It is true that a resource denoted by a URN may >> never have a digital representation instantiated at any given location, >> but that doesn't make such a URN the equivalent of a URP. > > But, to play "devil's advocate" for the contemporary paradigm (after > my earlier arguments in favor of a more elaborate taxonomy), "never" > is a very long time... things tend to change, sometimes in > unpredictable ways, but their names don't always change accordingly -- > look at the Los Angeles Lakers and Utah Jazz, whose team names made > more sense when they were the Minneapolis Lakers and New Orleans > Jazz. > > Thus, when somebody assigns a name in a particular URI scheme to > something based on his assessment of whether or not that "something" > ever will be resolvable on the Internet, this assessment may well be > contradicted by later events, leading to a need for a kludged-up > method of resolving URIs of a form that were supposed to be defined > to be unresolvable, or contrariwise, to the continued use of URIs to > things no longer resolvable that use schemes that indicate supposedly > resolvable resources, because they've embedded themselves as > identifiers in some context where they can't easily be changed. A very good point. Let me try to answer it in two halves: 1. A URI which is originally intended to denote a retrievable resource: if that resource later has no web-accessible representation or expression, that doesn't change the quality of that resource. The name of a person who lived does not suddenly become invalid once they die nor equivalent to the name of a fictitious person. Likewise, one may loose all copies of some resource, but that doesn't mean that the resource was abstract, or should be treated now as abstract, just because it is no longer retrievable. Do URLs then denote abstract resources when offline? ;-) 2. A URI which is originally intended to denote a non-retrievable resource: firstly, if the resource is abstract, or non-digital, then one would hardly expect it to suddently become retrievable in a digital context such as the web. One would only be able to retrieve secondary knowledge or representations of those non-retrievable resources, not the resources themselves. Taking a scifi view, if later one is able to digitize physical entities (beam me up, Scotty) then perhaps we have to rethink this, but I guess we have a little bit of time to philosophise around that one ;-) The key is the inherent, intended quality of retrievability or non-retrievability ascribed to the resource denoted by the URI, not whether the resource is or is not retrievable at some point in time or in some given context. Maybe that answers your question, maybe not, but that's my stab at it at the end of a long day... Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Jan 21 11:45:53 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16239 for ; Mon, 21 Jan 2002 11:45:53 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA04339; Mon, 21 Jan 2002 11:42:49 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11710 for URN-IETF@LISTS.NETSOL.COM; Mon, 21 Jan 2002 11:42:31 -0500 Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA04332 for ; Mon, 21 Jan 2002 11:42:30 -0500 (EST) Received: from hplns3.hpl.hp.com (hplns3.hpl.hp.com [15.0.48.4]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id IAA02165; Mon, 21 Jan 2002 08:36:27 -0800 (PST) Received: from tims-omnibook.hpl.hp.com (pal1nai161166.nsr.hp.com [15.244.161.166]) by hplns3.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id g0LGaOg22802; Mon, 21 Jan 2002 08:36:25 -0800 (PST) X-Sender: timothy@hplex1.hpl.hp.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <000e01c1a22c$f1aea5a0$06560150@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: Tim Kindberg Message-ID: <5.1.0.14.1.20020121081822.036cadc0@hplex1.hpl.hp.com> Date: Mon, 21 Jan 2002 08:42:55 -0800 Reply-To: Tim Kindberg From: Tim Kindberg Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: At 09:29 AM 1/21/02 +0200, Patrick Stickler wrote: >On 2002-01-21 5:37, "ext Sean B. Palmer" wrote: > > > Hi Patrick, > > > > Sorry for taking so long to go through your recent URx publications; > > here are some fairly innane questions, and some general comments. > > > > My first Q is about the hierarchial URN scheme. Michael pointed out > > that they can have domain names as authority components, which isn't > > all that persistent. UUIDs would be alright, but they're fairly > > difficult to generate. The other option is a tag-esque "domain,date" > > component - which brings me to the question: how does "hrn:" differ > > from "tag:"? As one of the people who devised tags -- http://www.ietf.org/internet-drafts/draft-kindberg-tag-uri-01.txt -- I'm having trouble understanding Patrick's hrn: design and his comments below. One of the rationales for tag: has always been to separate minting from binding and make minting convenient for humans, so we seem to share that. An important aspect of minting, obviously, is a guarantee of uniqueness. Email addresses and domain names belong to at most one entity at a time and are thererfore suitable 'seeds' for uniqueness -- hence we use them in tags. But they're not uniquely assigned over time. Therefore we qualify them with a date on which they're assigned: tag:timothy@hpl.hp.com,2002-01-21:ikaika, which is a name that I have just assigned for my dog, is guaranteed to be unique now and forever, because I own that email address on today's date. No-one -- in particular, a timothy@hpl.hp.com at HP in the year 2034 -- is allowed to mint a tag for any date other than one on which they own the email address/domain name, so they can never legitimately choose the same name. In contrast, the person who holds abc.com in 2034 might 're-mint' hrn://abc.com/288918293/3/en/global/docbook. At least, there may be no records of what previous owners of abc.com have minted, so the new minter can't be sure. As for the hierarchical nature of hrns -- sure, hierarchies are nice. But why mandate a syntax to that extent for the 'local' part of the identifier? It's nobody else's business; it just has to be unique. By the way, tag: is in the RFC editor's queue. It's also somewhere in the urn nid registration process. Tim. >As I pointed out in an earlier response, the use of the web >authority does not make an 'hrn:' non-persistent, as the >web authority in an 'hrn:' represents only the minting >authority, and not the resolution authority. In an 'http:' >URL, a web authority is both, and thus if it changes or >becomes inactive, the resolution authority becomes invalid >and thus persistence is impacted. > >'hrn:' URNs do not have that problem, even though web authorities >may be used, because the web authority remains historically valid >and even if it becomes inactive, that has no impact on the >persistent validity of the 'hrn:' URN. > >See section 3 of draft-pstickler-uri-taxonomy-00 regarding >these distinctions. > >The benefit of allowing a web authority as the minting authority >is that it provides a far less centralized method of "namespace" >than 'urn:' NIDs or purchasing of URIs from NID owners (e.g. DOI, >ISBN, etc.). With 'hrn:'s, anyone can mint a mnemonic URN >based on a web authority, or a non-mnemonic (or partially >mnemonic) URN based on a UUID easily and without fear of >collision. And those URNs can be hierarchically defined to boot. > >'hrn:' = "URN Power to the People" ;-) > > > I presume that the hierarchial aspect is what you're > > after, although I'm not sure what the relationship between the > > segments is. > >Hierarchy was one desired characteristic. Minimially-centrallized >minting was another (i.e. based on any web authority, not having >to register a namespace or pay some agency that has a namespace). > >Per above. > > > Why not use ":" as a hierarchial segment delimiter in > > "tag:"? > >Because there already is a standard syntax for hierarchical URIs and >many APIs and libraries exist for parsing such hierarchical URIs into >their components. > >Why introduce another hierarchical syntax if the present standard >does the job? > > > Note that "tag:" was going to be registered as a URI, and URN > > NID. > >I understand that. But it appears to me that it is only the >contemporary view that forces this redundancy. You should be >able to register it simply as a URI with a classification of URN. > >Or, you can register it as an NID of the 'urn:' scheme. > >Why do both? > >Having both 'xxx:foo' and 'urn:xxx:foo' is sure to result in >alot of needless overhead. > > > Next Q: I can't work out what "voc:" is for, if anything. The draft > > states: "This provides a more robust and safe treatment of unqualified > > names than the 'online:' or 'genid:' treatments employed by most RDF > > systems to date.", so it sounds as if they're meant to be replacements > > for anonymous nodes... but the structure of the URIs suggests > > otherwise. > >The use of 'voc:' in RDF for providing non-collisive identifiers >for local (not anonymous) resources is very much a fringe use. > >The 'voc:' URT scheme is intended for vocabularies. See the >examples in the I-D. That should clarify its intended usage. > >In short, for the URIs of all element and attribute names of all >XML content models, for the URIs of all resource names of all >RDF schemas, for the URIs of all controlled vocabularies >and taxonomies such as ISO language and country codes, TGN >geographic names, etc. etc. > >I.e. for all abstract identifiers. > >I think that the 'voc:' URT scheme is the most important of >all of the newly proposed schemes, and has the widest application. > > > I've also been wondering about the taxonomy in general. A lot of > > people will tell you that an HTTP URI is just as good a persistent > > identifier as any URN - it's the social contract that matters, and > > HTTP URIS are widely deployed. The URN/URL/URP taxonomy feels rather > > artificial to me, and I fear that creators of new schemes will have to > > beg to you as the arbiter of where a new scheme belongs. > >I agree that before such a taxonomy would reach the maturity >of a standard that it would need more precise definition. I think >though that the criteria distinguishing the proposed classes is >fairly straightforward. > >If your URI scheme denotes a point of access, it is a URL. If it >denotes an indirect access key, it is a URN, if it does not resolve >(is self contained) it is a URP. > >I.e.: > > URL direct resolution > URN indirect resolution > URP no resolution > > > [BTW, I'm not > > sure I would have chosen the acronym "URP". Every time I write it, I > > feel like excusing myself afterwards]. > >It does seem to give a few folks indigestion ;-) > > > For example, you've listed ESL as a URV. I can see the motivation > > behind that, and I would agree - if not for the fact that ESL could > > easily have been submitted as a URN NID. > >But why? Is the primary and fundamental purpose of an 'esl:' URI to >denote some other web resource independent of its location? > > > At the moment, I am one of > > those who feel that the boundary between URP and URN is not all that > > solid. [In fact, I wonder why there isn't a "uri-x:" alternative of > > "urn:urn-x:".] > > > > I'm not sure what the utility of the "qname:" scheme is. In fact, many > > of the drafts are lacking in describing the utility of the schemes > > themselves. Whilst this seems to be common practise, it's something > > that I battle against. All new schemes should have a detailed space > > describing their purpose and motivation, because it obviates arguments > > later on. If you could prepare a summary of the aims of each scheme, > > that would be rather useful. > >All of the schemes have specific utility but I tried to avoid being >too specific with regards to all possible applications, keeping each >I-D focused on the essential technical details regarding the URI >scheme in a generic fashion that would be as future-flexible as >possible. > >I am actually working on a more descriptive account of where/how each >is used, which, if I get it done in time, I will likely submit for >the SW track at WWW12. > >Cheers, > >Patrick > > >-- > >Patrick Stickler Phone: +358 50 483 9453 >Senior Research Scientist Fax: +358 7180 35409 >Nokia Research Center Email: patrick.stickler@nokia.com Tim Kindberg mobile systems and services lab hewlett-packard laboratories 1501 page mill road, ms 1u-17 palo alto ca 94304-1126 usa www.champignon.net/TimKindberg/ timothy@hpl.hp.com voice +1 650 857 5609 fax +1 650 857 2358 From owner-urn-ietf@LISTS.NETSOL.COM Tue Jan 22 09:35:30 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19625 for ; Tue, 22 Jan 2002 09:35:29 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA10043; Tue, 22 Jan 2002 09:33:26 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12342 for URN-IETF@LISTS.NETSOL.COM; Tue, 22 Jan 2002 09:33:09 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA10036 for ; Tue, 22 Jan 2002 09:33:07 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0MER6t01949 for ; Tue, 22 Jan 2002 16:27:06 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Jan 2002 16:27:02 +0200 Received: from [10.114.130.183] (tr-adsl-dhcp-130183.ntc.nokia.com [10.114.130.183]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0ZT6N58; Tue, 22 Jan 2002 16:27:02 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Tue, 22 Jan 2002 16:26:24 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <5.1.0.14.1.20020121081822.036cadc0@hplex1.hpl.hp.com> Content-Transfer-Encoding: 7bit On 2002-01-21 18:42, "ext Tim Kindberg" wrote: > At 09:29 AM 1/21/02 +0200, Patrick Stickler wrote: >> On 2002-01-21 5:37, "ext Sean B. Palmer" wrote: >> >>> Hi Patrick, >>> >>> Sorry for taking so long to go through your recent URx publications; >>> here are some fairly innane questions, and some general comments. >>> >>> My first Q is about the hierarchial URN scheme. Michael pointed out >>> that they can have domain names as authority components, which isn't >>> all that persistent. UUIDs would be alright, but they're fairly >>> difficult to generate. The other option is a tag-esque "domain,date" >>> component - which brings me to the question: how does "hrn:" differ >>> from "tag:"? > > As one of the people who devised tags -- > http://www.ietf.org/internet-drafts/draft-kindberg-tag-uri-01.txt -- I'm > having trouble understanding Patrick's hrn: design and his comments below. > > One of the rationales for tag: has always been to separate minting from > binding and make minting convenient for humans, so we seem to share that. > An important aspect of minting, obviously, is a guarantee of uniqueness. > Email addresses and domain names belong to at most one entity at a time and > are thererfore suitable 'seeds' for uniqueness -- hence we use them in > tags. But they're not uniquely assigned over time. Therefore we qualify > them with a date on which they're assigned: > > tag:timothy@hpl.hp.com,2002-01-21:ikaika, which is a name that I have just > assigned for my dog, is guaranteed to be unique now and forever, because I > own that email address on today's date. No-one -- in particular, a > timothy@hpl.hp.com at HP in the year 2034 -- is allowed to mint a tag for > any date other than one on which they own the email address/domain name, so > they can never legitimately choose the same name. > > In contrast, the person who holds abc.com in 2034 might 're-mint' > hrn://abc.com/288918293/3/en/global/docbook. At least, there may be no > records of what previous owners of abc.com have minted, so the new minter > can't be sure. I fully appreciate the benefit of guarunteed global and temporal uniqueness (hence support for UUIDs), but I feel that there are other means of anchoring names in time, not just by date, such as version numbers, and there is nothing to prevent you from including a date in an 'hrn:' root, similar to 'tag:' -- it simply isn't manditory. While the goal of persistence is one that all URN schemes should embrace, there are different degrees of persistence and different degrees of uniqueness, and given the intended use of 'hrn:'s felt it reasonable (if not proper) to leave it up to the minting authority to decide what degree of persistence is optimal. > As for the hierarchical nature of hrns -- sure, hierarchies are nice. But > why mandate a syntax to that extent for the 'local' part of the identifier? > It's nobody else's business; it just has to be unique. I'm not sure I follow you -- though per my unsure understanding, you would like to leave everything beyond the authority portion opaque? Well, there's no restriction about having "local" syntax for partitioning of any sort, and you can have any valid URI string (sans '/' characters) in your local part, with just one level of naming. Having a standardized representation for hierarchy, though, is very useful for scoping identifier models which define the identity of resources in terms of superordinate context. E.g. work/expression/realization/instance is a common hierarchy in the library/literature fields. We use a similar hierarchical, scoping identity model for modular digital resources here at Nokia. > By the way, tag: is in the RFC editor's queue. It's also somewhere in the > urn nid registration process. I am well aware of that, and wish the 'tag:' URI scheme well. In fact, I referenced it specifically in my I-D http://ietf.org/internet-drafts/draft-pstickler-uri-taxonomy-00.txt I will admit, however, that the intended purpose and utility of the 'tag:' and 'hrn:' URN schemes do overlap, and one advantage of the 'hrn:' scheme (having of course a biased view) is that the semantics of the 'hrn:' scheme expect an instance of that scheme to denote a retrievable digital resource whereas the 'tag:' URN/URT scheme may be used for either digital or non-digital resources, which introduces problems for software applications needing to decide what to do with one. Regards, Patrick > Tim. > > > > >> As I pointed out in an earlier response, the use of the web >> authority does not make an 'hrn:' non-persistent, as the >> web authority in an 'hrn:' represents only the minting >> authority, and not the resolution authority. In an 'http:' >> URL, a web authority is both, and thus if it changes or >> becomes inactive, the resolution authority becomes invalid >> and thus persistence is impacted. >> >> 'hrn:' URNs do not have that problem, even though web authorities >> may be used, because the web authority remains historically valid >> and even if it becomes inactive, that has no impact on the >> persistent validity of the 'hrn:' URN. >> >> See section 3 of draft-pstickler-uri-taxonomy-00 regarding >> these distinctions. >> >> The benefit of allowing a web authority as the minting authority >> is that it provides a far less centralized method of "namespace" >> than 'urn:' NIDs or purchasing of URIs from NID owners (e.g. DOI, >> ISBN, etc.). With 'hrn:'s, anyone can mint a mnemonic URN >> based on a web authority, or a non-mnemonic (or partially >> mnemonic) URN based on a UUID easily and without fear of >> collision. And those URNs can be hierarchically defined to boot. >> >> 'hrn:' = "URN Power to the People" ;-) >> >>> I presume that the hierarchial aspect is what you're >>> after, although I'm not sure what the relationship between the >>> segments is. >> >> Hierarchy was one desired characteristic. Minimially-centrallized >> minting was another (i.e. based on any web authority, not having >> to register a namespace or pay some agency that has a namespace). >> >> Per above. >> >>> Why not use ":" as a hierarchial segment delimiter in >>> "tag:"? >> >> Because there already is a standard syntax for hierarchical URIs and >> many APIs and libraries exist for parsing such hierarchical URIs into >> their components. >> >> Why introduce another hierarchical syntax if the present standard >> does the job? >> >>> Note that "tag:" was going to be registered as a URI, and URN >>> NID. >> >> I understand that. But it appears to me that it is only the >> contemporary view that forces this redundancy. You should be >> able to register it simply as a URI with a classification of URN. >> >> Or, you can register it as an NID of the 'urn:' scheme. >> >> Why do both? >> >> Having both 'xxx:foo' and 'urn:xxx:foo' is sure to result in >> alot of needless overhead. >> >>> Next Q: I can't work out what "voc:" is for, if anything. The draft >>> states: "This provides a more robust and safe treatment of unqualified >>> names than the 'online:' or 'genid:' treatments employed by most RDF >>> systems to date.", so it sounds as if they're meant to be replacements >>> for anonymous nodes... but the structure of the URIs suggests >>> otherwise. >> >> The use of 'voc:' in RDF for providing non-collisive identifiers >> for local (not anonymous) resources is very much a fringe use. >> >> The 'voc:' URT scheme is intended for vocabularies. See the >> examples in the I-D. That should clarify its intended usage. >> >> In short, for the URIs of all element and attribute names of all >> XML content models, for the URIs of all resource names of all >> RDF schemas, for the URIs of all controlled vocabularies >> and taxonomies such as ISO language and country codes, TGN >> geographic names, etc. etc. >> >> I.e. for all abstract identifiers. >> >> I think that the 'voc:' URT scheme is the most important of >> all of the newly proposed schemes, and has the widest application. >> >>> I've also been wondering about the taxonomy in general. A lot of >>> people will tell you that an HTTP URI is just as good a persistent >>> identifier as any URN - it's the social contract that matters, and >>> HTTP URIS are widely deployed. The URN/URL/URP taxonomy feels rather >>> artificial to me, and I fear that creators of new schemes will have to >>> beg to you as the arbiter of where a new scheme belongs. >> >> I agree that before such a taxonomy would reach the maturity >> of a standard that it would need more precise definition. I think >> though that the criteria distinguishing the proposed classes is >> fairly straightforward. >> >> If your URI scheme denotes a point of access, it is a URL. If it >> denotes an indirect access key, it is a URN, if it does not resolve >> (is self contained) it is a URP. >> >> I.e.: >> >> URL direct resolution >> URN indirect resolution >> URP no resolution >> >>> [BTW, I'm not >>> sure I would have chosen the acronym "URP". Every time I write it, I >>> feel like excusing myself afterwards]. >> >> It does seem to give a few folks indigestion ;-) >> >>> For example, you've listed ESL as a URV. I can see the motivation >>> behind that, and I would agree - if not for the fact that ESL could >>> easily have been submitted as a URN NID. >> >> But why? Is the primary and fundamental purpose of an 'esl:' URI to >> denote some other web resource independent of its location? >> >>> At the moment, I am one of >>> those who feel that the boundary between URP and URN is not all that >>> solid. [In fact, I wonder why there isn't a "uri-x:" alternative of >>> "urn:urn-x:".] >>> >>> I'm not sure what the utility of the "qname:" scheme is. In fact, many >>> of the drafts are lacking in describing the utility of the schemes >>> themselves. Whilst this seems to be common practise, it's something >>> that I battle against. All new schemes should have a detailed space >>> describing their purpose and motivation, because it obviates arguments >>> later on. If you could prepare a summary of the aims of each scheme, >>> that would be rather useful. >> >> All of the schemes have specific utility but I tried to avoid being >> too specific with regards to all possible applications, keeping each >> I-D focused on the essential technical details regarding the URI >> scheme in a generic fashion that would be as future-flexible as >> possible. >> >> I am actually working on a more descriptive account of where/how each >> is used, which, if I get it done in time, I will likely submit for >> the SW track at WWW12. >> >> Cheers, >> >> Patrick >> >> >> -- >> >> Patrick Stickler Phone: +358 50 483 9453 >> Senior Research Scientist Fax: +358 7180 35409 >> Nokia Research Center Email: patrick.stickler@nokia.com > > > Tim Kindberg > > mobile systems and services lab hewlett-packard laboratories > 1501 page mill road, ms 1u-17 > palo alto > ca 94304-1126 > usa > > www.champignon.net/TimKindberg/ > timothy@hpl.hp.com > voice +1 650 857 5609 > fax +1 650 857 2358 > > -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Tue Jan 22 09:39:07 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19808 for ; Tue, 22 Jan 2002 09:39:06 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA10122; Tue, 22 Jan 2002 09:36:55 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12339 for URN-IETF@LISTS.NETSOL.COM; Tue, 22 Jan 2002 09:36:53 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from smtprelay7.dc2.adelphia.net (smtprelay7.dc2.adelphia.net [64.8.50.39]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA09834 for ; Tue, 22 Jan 2002 08:53:34 -0500 (EST) Received: from 21afr ([24.51.220.230]) by smtprelay7.dc2.adelphia.net (Netscape Messaging Server 4.15) with ESMTP id GQCEAE00.OYA; Tue, 22 Jan 2002 08:47:02 -0500 MIME-Version: 1.0 Priority: normal References: X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Message-ID: <3C4D26F4.25248.E3900D9@localhost> Date: Tue, 22 Jan 2002 08:46:44 -0500 Reply-To: "Daniel R. Tobias" From: "Daniel R. Tobias" Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <5.1.0.14.1.20020121081822.036cadc0@hplex1.hpl.hp.com> Content-Transfer-Encoding: 7BIT > tag:timothy@hpl.hp.com,2002-01-21:ikaika, which is a name that I have just > assigned for my dog, is guaranteed to be unique now and forever, because I > own that email address on today's date. No-one -- in particular, a > timothy@hpl.hp.com at HP in the year 2034 -- is allowed to mint a tag for > any date other than one on which they own the email address/domain name, so > they can never legitimately choose the same name. > > In contrast, the person who holds abc.com in 2034 might 're-mint' > hrn://abc.com/288918293/3/en/global/docbook. At least, there may be no > records of what previous owners of abc.com have minted, so the new minter > can't be sure. Actually, the "guarantee" of uniqueness is only as good as the minting authorities make it... the spec doesn't require you to use today's date in the URI, only some date when you were in control of the given address -- in 2034, ABC would be able to continue to issue tag:abc.com,2001 URIs if they wished (whether or not they still owned that domain name in 2034, given that they owned it in 2001), and they might reuse one due to forgetfulness or because URI issuing was placed in the charge of some knucklehead marketing type who says "I don't *care* if we used that same URI 20 years ago for something else... nobody remembers that ancient history, and I like how it looks, so I want to use it now, and I'm the boss!" Even when people use today's date in tag: URIs, some might be sufficiently absent-minded to use the same one twice within the same day, or have the issuance be done by a discoordinated organization where one hand doesn't know what the other is doing and different people keep stepping on one another's toes. Thus, no standards document is truly going to guarantee uniqueness of URIs... it's up to the people who issue and use them. > By the way, tag: is in the RFC editor's queue. It's also somewhere in the > urn nid registration process. I'd like to know just "what's the deal" with these dual URN namespace / URI scheme registrations. If they're approved this way, which form are the users and developers supposed to use, the urn:foo: one or the foo: one? Does it depend on whether the user anticipates that the resource will, some day, be possibly resolvable on the Internet? It seems like these dual-nature URI schemes will result in there being multiple URIs for the same resource as the urn: part gets added and dropped capriciously. -- == Dan == Dan's Web Tips: http://www.dantobias.com/webtips/ Dan's Domain Site: http://domains.dantobias.com/ From owner-urn-ietf@LISTS.NETSOL.COM Tue Jan 22 12:37:58 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01711 for ; Tue, 22 Jan 2002 12:37:58 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA11549; Tue, 22 Jan 2002 12:32:29 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12609 for URN-IETF@LISTS.NETSOL.COM; Tue, 22 Jan 2002 12:31:37 -0500 Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA11542 for ; Tue, 22 Jan 2002 12:31:35 -0500 (EST) Received: from hplns3.hpl.hp.com (hplns3.hpl.hp.com [15.0.48.4]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id JAA15611; Tue, 22 Jan 2002 09:25:32 -0800 (PST) Received: from timpc.hpl.hp.com (timpc.hpl.hp.com [15.4.92.160]) by hplns3.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id g0MHPVL29905; Tue, 22 Jan 2002 09:25:32 -0800 (PST) X-Sender: timothy@hplex1.hpl.hp.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.1.20020121081822.036cadc0@hplex1.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: Tim Kindberg Message-ID: <5.1.0.14.1.20020122085516.02391808@hplex1.hpl.hp.com> Date: Tue, 22 Jan 2002 09:25:28 -0800 Reply-To: Tim Kindberg From: Tim Kindberg Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3C4D26F4.25248.E3900D9@localhost> At 08:46 AM 1/22/2002 -0500, Daniel R. Tobias wrote: >Actually, the "guarantee" of uniqueness is only as good as the >minting authorities make it... the spec doesn't require you to use >today's date in the URI, only some date when you were in control of >the given address -- in 2034, ABC would be able to continue to issue >tag:abc.com,2001 URIs if they wished (whether or not they still owned >that domain name in 2034, given that they owned it in 2001), and they >might reuse one due to forgetfulness or because URI issuing was >placed in the charge of some knucklehead marketing type who says "I >don't *care* if we used that same URI 20 years ago for something >else... nobody remembers that ancient history, and I like how it >looks, so I want to use it now, and I'm the boss!" > >Even when people use today's date in tag: URIs, some might be >sufficiently absent-minded to use the same one twice within the same >day, or have the issuance be done by a discoordinated organization >where one hand doesn't know what the other is doing and different >people keep stepping on one another's toes. And neither does our draft state that users should not stick pins in themselves. I take it for granted that identification relies on many factors that have to do with 'good practice'. As systems designers we can only try to create openings that prove (or don't prove) to satisfy a need and that are within the limits of people's budgets and competencies. > > By the way, tag: is in the RFC editor's queue. It's also somewhere in the > > urn nid registration process. > >I'd like to know just "what's the deal" with these dual URN namespace >/ URI scheme registrations. If they're approved this way, which form >are the users and developers supposed to use, the urn:foo: one or the >foo: one? Does it depend on whether the user anticipates that the >resource will, some day, be possibly resolvable on the Internet? It >seems like these dual-nature URI schemes will result in there being >multiple URIs for the same resource as the urn: part gets added and >dropped capriciously. Each scheme that has, for one reason or another (mostly trying to keep their heads above the mire in the boggy mess that is URL-land), pursued dual registration, should specify whether foo:x is the same as urn:foo:x. I believe that we're lacking in that respect and I'll fix it. By the way, we view the one namespace as a simple embedding of the other, so tag:x and urn:tag:x are the same _identifiers_ (I didn't refer to bindings), for all x. Tim. Tim Kindberg mobile systems and services lab hewlett-packard laboratories 1501 page mill road, ms 1u-17 palo alto ca 94304-1126 usa www.champignon.net/TimKindberg/ timothy@hpl.hp.com voice +1 650 857 5609 fax +1 650 857 2358 From owner-urn-ietf@LISTS.NETSOL.COM Tue Jan 22 12:46:11 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02011 for ; Tue, 22 Jan 2002 12:46:10 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA11763; Tue, 22 Jan 2002 12:44:29 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12660 for URN-IETF@LISTS.NETSOL.COM; Tue, 22 Jan 2002 12:44:25 -0500 Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA11756 for ; Tue, 22 Jan 2002 12:44:24 -0500 (EST) Received: from hplns3.hpl.hp.com (hplns3.hpl.hp.com [15.0.48.4]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id JAA16696; Tue, 22 Jan 2002 09:38:21 -0800 (PST) Received: from timpc.hpl.hp.com (timpc.hpl.hp.com [15.4.92.160]) by hplns3.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id g0MHcJL29969; Tue, 22 Jan 2002 09:38:19 -0800 (PST) X-Sender: timothy@hplex1.hpl.hp.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.1.20020121081822.036cadc0@hplex1.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: Tim Kindberg Message-ID: <5.1.0.14.1.20020122092613.023b0008@hplex1.hpl.hp.com> Date: Tue, 22 Jan 2002 09:38:18 -0800 Reply-To: Tim Kindberg From: Tim Kindberg Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: At 04:26 PM 1/22/2002 +0200, Patrick Stickler wrote: >I fully appreciate the benefit of guarunteed global and temporal >uniqueness (hence support for UUIDs), but I feel that there are >other means of anchoring names in time, not just by date, such >as version numbers, and there is nothing to prevent you from including >a date in an 'hrn:' root, similar to 'tag:' -- it simply isn't >manditory. But 'version numbers' don't necessarily cross organisations whereas dates do. Our view is that you have to mandate some type of framework for the coherence of the name space. > > As for the hierarchical nature of hrns -- sure, hierarchies are nice. But > > why mandate a syntax to that extent for the 'local' part of the identifier? > > It's nobody else's business; it just has to be unique. > >I'm not sure I follow you -- though per my unsure understanding, >you would like to leave everything beyond the authority portion >opaque? That's what we do. >Well, there's no restriction about having "local" syntax for >partitioning of any sort, and you can have any valid URI string >(sans '/' characters) in your local part, with just one level >of naming. But my point is: why frame or constrain where there is no global need to do so? We should agree on as little as possible (Occam's Razor for naming schemes). >Having a standardized representation for hierarchy, though, >is very useful for scoping identifier models which define the >identity of resources in terms of superordinate context. > >E.g. work/expression/realization/instance is a common hierarchy >in the library/literature fields. I'm happy to let such communities develop their own standards but it's none of my business. >I will admit, however, that the intended purpose and utility >of the 'tag:' and 'hrn:' URN schemes do overlap, and one >advantage of the 'hrn:' scheme (having of course a biased >view) is that the semantics of the 'hrn:' scheme expect an >instance of that scheme to denote a retrievable digital >resource whereas the 'tag:' URN/URT scheme may be used for >either digital or non-digital resources, which introduces >problems for software applications needing to decide what >to do with one. One of our intended use models is indeed that people can attach tags to physical entities but the point of doing so is for users to retrieve digital resources from them (http://www.hpl.hp.com/techreports/2001/HPL-2001-95.html). So I don't see the difference. Cheers, Tim. Tim Kindberg mobile systems and services lab hewlett-packard laboratories 1501 page mill road, ms 1u-17 palo alto ca 94304-1126 usa www.champignon.net/TimKindberg/ timothy@hpl.hp.com voice +1 650 857 5609 fax +1 650 857 2358 From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 05:49:56 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05246 for ; Wed, 23 Jan 2002 05:49:56 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id FAA16442; Wed, 23 Jan 2002 05:45:29 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13210 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 05:45:16 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id FAA16435 for ; Wed, 23 Jan 2002 05:45:14 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0NAdEt12670 for ; Wed, 23 Jan 2002 12:39:14 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 23 Jan 2002 12:39:11 +0200 Received: from [10.114.130.183] (tr-adsl-dhcp-130183.ntc.nokia.com [10.114.130.183]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0ZT8D92; Wed, 23 Jan 2002 12:39:10 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Wed, 23 Jan 2002 12:21:13 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <5.1.0.14.1.20020122085516.02391808@hplex1.hpl.hp.com> Content-Transfer-Encoding: 7bit On 2002-01-22 19:25, "ext Tim Kindberg" wrote: > At 08:46 AM 1/22/2002 -0500, Daniel R. Tobias wrote: >> Actually, the "guarantee" of uniqueness is only as good as the >> minting authorities make it... ... > > ... I take it for granted that identification relies on many > factors that have to do with 'good practice'. As systems designers we can > only try to create openings that prove (or don't prove) to satisfy a need > and that are within the limits of people's budgets and competencies. In principle, I fully agree, though in practice, I prefer solutions that facilitate and encourage what is percieved as optimal without mandating or forcing what is percieved as optimal, because needs/understanding change and needs/opinions vary. Thus, you can create an 'hrn:' that is, according to the UUID specification, guarunteed to be globally and temporally unique (presuming a valid implementation) while still adding mnemonic components to it if desired. E.g. hrn://-/f81d4fae-7dec-11d0-a765-00a0c91e6bf6 or hrn://-/f81d4fae-7dec-11d0-a765-00a0c91e6bf6/Chapter1 One can also, as per 'tag:', anchor one's 'hrn:' temporally by date, e.g. hrn://abc.com/2002/FinancialReport/Introduction or at higher resolution hrn://abc.com/2002/01/22/FinancialReport/Introduction Or one can use other means to denote temporal ordering, such as version numbering, e.g. hrn://abc.com/InductionGuide-v2.7 Or one can use proprietary components that ensure temporal uniqueness, such as managed sequences of identifiers, e.g. hrn://abc.com/abcid_881819923819/Chapter1 Or one can simply trust that the name is so significant within the context of the minting authority that it will never be reused, and thus ambiguity will never arise, e.g. hrn://john.doe@abc.com/resume In short, it's up to the minting authority to decide just how strict or loose the requirements are for temporal and/or global uniqueness -- with each of the options having more or less overhead to use (granted, some discussion regarding global and temporal uniqueness and how to best achieve that would likely be a good addition to the final 'hrn:' RFC, and I've made a note of that). A generalized URN scheme must provide the utility and flexibility needed to accomodate common naming practices while still providing for the needs of most or all users, including absolute temporal and global uniqueness if so desired/needed. With regards to temporal anchoring, 'tag:' seems to me to be too "mothering" and not general enough. And as has been pointed out, does not provide a form that garuntees against accidental collision within the same authority (e.g. UUID). Thus, 'hrn:' is both more general and more precise than 'tag:'. If absolute temporal and global uniqueness is paramount, there are other URN schemes that can be used, and agencies that will ensure that uniqueness for all instances of such schemes no matter what, but for a price (e.g. DOI, ISBN, etc.). >>> By the way, tag: is in the RFC editor's queue. It's also somewhere in the >>> urn nid registration process. >> >> I'd like to know just "what's the deal" with these dual URN namespace >> / URI scheme registrations. ... > > ... By the way, we > view the one namespace as a simple embedding of the other, so tag:x and > urn:tag:x are the same _identifiers_ (I didn't refer to bindings), for all x. It's nice that *you* view them as the same, but how are applications (or humans) to know that they are the same? I think that the IETF should *heavily* discourage, if not disallow dual registration of equivalent URI and URN NID schemes. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 05:53:30 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05278 for ; Wed, 23 Jan 2002 05:53:30 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id FAA16511; Wed, 23 Jan 2002 05:49:20 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13228 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 05:49:09 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id FAA16504 for ; Wed, 23 Jan 2002 05:49:02 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0NAh2t15494 for ; Wed, 23 Jan 2002 12:43:02 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 23 Jan 2002 12:42:58 +0200 Received: from [10.114.130.183] (tr-adsl-dhcp-130183.ntc.nokia.com [10.114.130.183]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0ZT81BV; Wed, 23 Jan 2002 12:42:48 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Wed, 23 Jan 2002 12:43:47 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <5.1.0.14.1.20020122092613.023b0008@hplex1.hpl.hp.com> Content-Transfer-Encoding: 7bit On 2002-01-22 19:38, "ext Tim Kindberg" wrote: > At 04:26 PM 1/22/2002 +0200, Patrick Stickler wrote: > > > >> I fully appreciate the benefit of guarunteed global and temporal >> uniqueness (hence support for UUIDs), but I feel that there are >> other means of anchoring names in time, not just by date, such >> as version numbers, and there is nothing to prevent you from including >> a date in an 'hrn:' root, similar to 'tag:' -- it simply isn't >> manditory. > > But 'version numbers' don't necessarily cross organisations whereas dates > do. Our view is that you have to mandate some type of framework for the > coherence of the name space. But "mandates" in general seldom succeed. You must support the practices and traditions of the minting authorities. It is up to the minting authority to determine what is needed, and in my experience, it is seldom that the current practice does not suffice. Forcing all organizations worldwide to change the way they construct identifiers (apart from educating them on the issues relating to globally and temporally unique idenfiers in a web context and showing them how they can best achieve that) is not going to work. Most large organizations have very well established methods for achieving unique names within the scope of that organization, and the 'hrn:' scheme is a way for them to capture those methods in a URI without having to re-engineer those methods or processes (unless they choose to). >>> As for the hierarchical nature of hrns -- sure, hierarchies are nice. But >>> why mandate a syntax to that extent for the 'local' part of the identifier? >>> It's nobody else's business; it just has to be unique. >> >> I'm not sure I follow you -- though per my unsure understanding, >> you would like to leave everything beyond the authority portion >> opaque? > > That's what we do. But why should the rest of the world also live with that restriction. Many folks *need* hierarchical identifiers. >> Well, there's no restriction about having "local" syntax for >> partitioning of any sort, and you can have any valid URI string >> (sans '/' characters) in your local part, with just one level >> of naming. > > But my point is: why frame or constrain where there is no global need to do > so? We should agree on as little as possible (Occam's Razor for naming > schemes). Where on earth do you get the idea that there is no need to do so. Just because you don't need to, or just because everybody doesn't need to, does not mean it is not a widespread need. >> Having a standardized representation for hierarchy, though, >> is very useful for scoping identifier models which define the >> identity of resources in terms of superordinate context. >> >> E.g. work/expression/realization/instance is a common hierarchy >> in the library/literature fields. > > I'm happy to let such communities develop their own standards but it's none > of my business. Then why are you commenting on the 'hrn:' scheme? It is a standard for global naming for communities which desire hierarchical URNs. If you don't care about hierarchical URNs, then you shouldn't care about the 'hrn:' URN scheme. No? >> I will admit, however, that the intended purpose and utility >> of the 'tag:' and 'hrn:' URN schemes do overlap, and one >> advantage of the 'hrn:' scheme (having of course a biased >> view) is that the semantics of the 'hrn:' scheme expect an >> instance of that scheme to denote a retrievable digital >> resource whereas the 'tag:' URN/URT scheme may be used for >> either digital or non-digital resources, which introduces >> problems for software applications needing to decide what >> to do with one. > > One of our intended use models is indeed that people can attach tags to > physical entities but the point of doing so is for users to retrieve > digital resources from them > (http://www.hpl.hp.com/techreports/2001/HPL-2001-95.html). So I don't see > the difference. I don't follow. How do you retrieve a digital resource "from" a non-digital resource? Do you mean e.g. a book which may both be printed and available in digital form? In such a case, we have several "entities", we have the abstract work, and an expression of that work (e.g. in a given language), and for that expression, two manifestations, one which is physical and one which is digital. Only the last, the digital manifestation, would be a URN denoted resource, leading from the definition of a URN as an indirect point of access for a digital (web) resource. C.f. http://www.ifla.org/VII/s13/frbr/frbr.htm Regards, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 06:13:32 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05539 for ; Wed, 23 Jan 2002 06:13:32 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA16915; Wed, 23 Jan 2002 06:09:17 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13320 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 06:09:14 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA16908 for ; Wed, 23 Jan 2002 06:09:12 -0500 (EST) Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0NB2pj15534 for ; Wed, 23 Jan 2002 13:02:51 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 23 Jan 2002 13:03:11 +0200 Received: from [10.114.130.183] (tr-adsl-dhcp-130183.ntc.nokia.com [10.114.130.183]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0ZT8169; Wed, 23 Jan 2002 13:03:08 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Wed, 23 Jan 2002 13:04:06 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: FW: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Content-Transfer-Encoding: 7bit Seems my reply only went to Daniel and not to the list... ------ Forwarded Message From: Patrick Stickler Date: Mon, 21 Jan 2002 18:25:05 +0200 To: "Daniel R. Tobias" , URN Cc: URI Subject: Re: URx Questions On 2002-01-21 17:46, "ext Daniel R. Tobias" wrote: > On 21 Jan 2002 at 17:11, Patrick Stickler wrote: > >> There is, I feel, a significant difference between might not resolve >> and must not resolve. It is true that a resource denoted by a URN may >> never have a digital representation instantiated at any given location, >> but that doesn't make such a URN the equivalent of a URP. > > But, to play "devil's advocate" for the contemporary paradigm (after > my earlier arguments in favor of a more elaborate taxonomy), "never" > is a very long time... things tend to change, sometimes in > unpredictable ways, but their names don't always change accordingly -- > look at the Los Angeles Lakers and Utah Jazz, whose team names made > more sense when they were the Minneapolis Lakers and New Orleans > Jazz. > > Thus, when somebody assigns a name in a particular URI scheme to > something based on his assessment of whether or not that "something" > ever will be resolvable on the Internet, this assessment may well be > contradicted by later events, leading to a need for a kludged-up > method of resolving URIs of a form that were supposed to be defined > to be unresolvable, or contrariwise, to the continued use of URIs to > things no longer resolvable that use schemes that indicate supposedly > resolvable resources, because they've embedded themselves as > identifiers in some context where they can't easily be changed. A very good point. Let me try to answer it in two halves: 1. A URI which is originally intended to denote a retrievable resource: if that resource later has no web-accessible representation or expression, that doesn't change the quality of that resource. The name of a person who lived does not suddenly become invalid once they die nor equivalent to the name of a fictitious person. Likewise, one may loose all copies of some resource, but that doesn't mean that the resource was abstract, or should be treated now as abstract, just because it is no longer retrievable. Do URLs then denote abstract resources when offline? ;-) 2. A URI which is originally intended to denote a non-retrievable resource: firstly, if the resource is abstract, or non-digital, then one would hardly expect it to suddently become retrievable in a digital context such as the web. One would only be able to retrieve secondary knowledge or representations of those non-retrievable resources, not the resources themselves. Taking a scifi view, if later one is able to digitize physical entities (beam me up, Scotty) then perhaps we have to rethink this, but I guess we have a little bit of time to philosophise around that one ;-) The key is the inherent, intended quality of retrievability or non-retrievability ascribed to the resource denoted by the URI, not whether the resource is or is not retrievable at some point in time or in some given context. Maybe that answers your question, maybe not, but that's my stab at it at the end of a long day... Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com ------ End of Forwarded Message From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 09:10:51 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09053 for ; Wed, 23 Jan 2002 09:10:51 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA18397; Wed, 23 Jan 2002 09:08:51 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13592 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 09:08:46 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA18390 for ; Wed, 23 Jan 2002 09:08:44 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0NE2ft05059 for ; Wed, 23 Jan 2002 16:02:41 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 23 Jan 2002 16:02:37 +0200 Received: from [10.114.130.183] (tr-adsl-dhcp-130183.ntc.nokia.com [10.114.130.183]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0ZT8L8G; Wed, 23 Jan 2002 16:02:34 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Wed, 23 Jan 2002 16:03:33 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Useful analogy for URL/URN/URP distinctions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Content-Transfer-Encoding: 7bit The following analogy, or rather an expansion of it, came to me during a related discussion on the RDF Core WG list regarding "what is a resource"... --- [snip] On 2002-01-23 12:45, "ext Graham Klyne" wrote: > ... > roughly, a URI denotes a function that, when applied to some arguments, > returns some data entity... That's an interesting way to look at it, and in fact, a useful analogy for the difference between URL/URN/URP is that a URL is a function, a URN is a pointer to a function (possibly null) and a URP is a constant. Hmmm... --- [snip] Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com ------ End of Forwarded Message From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 12:24:30 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17215 for ; Wed, 23 Jan 2002 12:24:30 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA19424; Wed, 23 Jan 2002 12:22:38 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13725 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 12:22:26 -0500 Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA19417 for ; Wed, 23 Jan 2002 12:22:24 -0500 (EST) Received: from hplns3.hpl.hp.com (hplns3.hpl.hp.com [15.0.48.4]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id JAA00304; Wed, 23 Jan 2002 09:16:20 -0800 (PST) Received: from timpc.hpl.hp.com (timpc.hpl.hp.com [15.4.92.160]) by hplns3.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id g0NHGHG07065; Wed, 23 Jan 2002 09:16:18 -0800 (PST) X-Sender: timothy@hplex1.hpl.hp.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.1.20020122085516.02391808@hplex1.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: Tim Kindberg Message-ID: <5.1.0.14.1.20020123085640.01d9d3c8@hplex1.hpl.hp.com> Date: Wed, 23 Jan 2002 09:16:16 -0800 Reply-To: Tim Kindberg From: Tim Kindberg Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: At 12:21 PM 1/23/2002 +0200, Patrick Stickler wrote: >With regards to temporal anchoring, 'tag:' seems to me to be >too "mothering" and not general enough. You seem to have missed the point of tag. Without date qualification (or something much more laborious), an entity that holds an authority name could pollute the namespace of another entity that earlier held it. The restriction is solely to guard against that. It is not exactly a resource-hungry restriction. Of course, if you really want to, you could buy some DOIs instead (assuming that _they_ will always be around). But we wanted to allow individuals and small organisations to participate in naming at little or no cost -- that includes those who possess only an email address (or domain name). Email addresses are quite frequently given up as users change ISPs so the chances of someone else getting the same authority name are not negligible. >And as has been pointed >out, does not provide a form that garuntees against accidental >collision within the same authority (e.g. UUID). >I think that the IETF should *heavily* discourage, if not disallow >dual registration of equivalent URI and URN NID schemes. I agree with you. Tag is not where it is by overall design but by where and how we thought we could add value at the time. I think it's a mess that we have both registrations going but 'the system' is a mess and I'm not yet sure what to do to right our situation. I'm hoping that one or other registration will reach a stage when the solution to the problem becomes clear. Cheers, Tim. Tim Kindberg mobile systems and services lab hewlett-packard laboratories 1501 page mill road, ms 1u-17 palo alto ca 94304-1126 usa www.champignon.net/TimKindberg/ timothy@hpl.hp.com voice +1 650 857 5609 fax +1 650 857 2358 From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 12:27:04 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17299 for ; Wed, 23 Jan 2002 12:27:04 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA19445; Wed, 23 Jan 2002 12:24:59 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13731 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 12:24:56 -0500 Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA19438 for ; Wed, 23 Jan 2002 12:24:55 -0500 (EST) Received: from hplns3.hpl.hp.com (hplns3.hpl.hp.com [15.0.48.4]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id JAA00839; Wed, 23 Jan 2002 09:18:51 -0800 (PST) Received: from timpc.hpl.hp.com (timpc.hpl.hp.com [15.4.92.160]) by hplns3.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id g0NHIoG07069; Wed, 23 Jan 2002 09:18:50 -0800 (PST) X-Sender: timothy@hplex1.hpl.hp.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.1.20020122092613.023b0008@hplex1.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: Tim Kindberg Message-ID: <5.1.0.14.1.20020123074050.03649280@hplex1.hpl.hp.com> Date: Wed, 23 Jan 2002 09:18:49 -0800 Reply-To: Tim Kindberg From: Tim Kindberg Subject: tags To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: At 12:43 PM 1/23/02 +0200, Patrick Stickler wrote: >But why should the rest of the world also live with that >restriction. Many folks *need* hierarchical identifiers. ? tag doesn't deny them that: whatever follows the may be hierarchical. > > > > I'm happy to let such communities develop their own standards but it's none > > of my business. > >Then why are you commenting on the 'hrn:' scheme? I was talking about the tag scheme. But I'm also entitled to point out what I believe to be deficiencies in other proposals. I thought that that what this forum was for. > > One of our intended use models is indeed that people can attach tags to > > physical entities but the point of doing so is for users to retrieve > > digital resources from them > > (http://www.hpl.hp.com/techreports/2001/HPL-2001-95.html). So I don't see > > the difference. > >I don't follow. How do you retrieve a digital resource >"from" a non-digital resource? You read the identifier with a sensor (e.g. a camera, barcode reader, ...) and send the identifier to a resolver, which looks it up and returns the URLs of one or more corresponding resources. >Do you mean e.g. a book which may both be printed and available >in digital form? That would be one example. But one could associate (the identifier on) the book with many other types of digital resource, depending upon the application. Tag has nothing to say about the allowed types of binding. Tim. Tim Kindberg mobile systems and services lab hewlett-packard laboratories 1501 page mill road, ms 1u-17 palo alto ca 94304-1126 usa www.champignon.net/TimKindberg/ timothy@hpl.hp.com voice +1 650 857 5609 fax +1 650 857 2358 From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 13:32:30 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19624 for ; Wed, 23 Jan 2002 13:32:30 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA20545; Wed, 23 Jan 2002 13:30:43 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13963 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 13:30:25 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from email8.net ([65.112.130.132]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA20449 for ; Wed, 23 Jan 2002 13:18:07 -0500 (EST) Received: from [65.112.130.130] (HELO dan) by email8.net (CommuniGate Pro SMTP 3.4.3) with ESMTP id 1538168; Wed, 23 Jan 2002 13:12:28 -0500 MIME-Version: 1.0 Priority: normal References: X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Message-ID: <3C4EB689.26025.475BB20F@localhost> Date: Wed, 23 Jan 2002 13:11:37 -0500 Reply-To: dan@DANTOBIAS.COM From: dan@DANTOBIAS.COM Subject: Re: tags To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <5.1.0.14.1.20020123074050.03649280@hplex1.hpl.hp.com> Content-Transfer-Encoding: 7BIT On 23 Jan 2002 at 9:18, Tim Kindberg wrote: > >I don't follow. How do you retrieve a digital resource > >"from" a non-digital resource? > > You read the identifier with a sensor (e.g. a camera, barcode reader, ...) > and send the identifier to a resolver, which looks it up and returns the > URLs of one or more corresponding resources. In that case, the URI of the original offline resource is *not* being dereferenced to an online resource that is "at" that URI; the paradigm rather seems to be more that of hyperlinks, where various online resources, at different URIs, can be "linked from" or "associated with" the offline resource. In that case, the offline resource's URI is the URI of that resource, not of the things it points to or that have been associated with it. When you scan it and find associated links, you're not "resolving" the original URI as a URN might be, where it leads you to a current instance of the original resource, but rather you're using it as a launching point to find other resources that are relevant to the original one, each of which has a URI of its own (a URL, or maybe a URN that can be resolved to a URL). So, if I decide to assign URIs to each comic book in my collection, I know that I can't actually retrieve the comic book by typing that into a browser (or even scanning it from a bar code I've attached to the plastic bag I'm storing the comic in), but there might be online things associated with it, both private to me and public, such as a database record of when, where, and for how much I purchased it, a review of the storyline, a scanned graphic of the cover, an Ebay page where I'm currently trying to sell it, etc.; a smart user agent might be able to retrieve those things, but the URI of the comic itself wouldn't be the URI of any of them, just associated with it... just like the URLs I link to from my Web pages aren't the URLs of my Web page itself but merely other resources I'm associating with it. -- Dan Tobias, Programmer/Webmaster From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 13:52:42 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20443 for ; Wed, 23 Jan 2002 13:52:42 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA20848; Wed, 23 Jan 2002 13:51:23 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14038 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 13:51:19 -0500 Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA20841 for ; Wed, 23 Jan 2002 13:51:18 -0500 (EST) Received: from hplns3.hpl.hp.com (hplns3.hpl.hp.com [15.0.48.4]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id KAA18004; Wed, 23 Jan 2002 10:45:06 -0800 (PST) Received: from timpc.hpl.hp.com (timpc.hpl.hp.com [15.4.92.160]) by hplns3.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id g0NIj3G07343; Wed, 23 Jan 2002 10:45:03 -0800 (PST) X-Sender: timothy@hplex1.hpl.hp.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.1.20020123074050.03649280@hplex1.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: Tim Kindberg Message-ID: <5.1.0.14.1.20020123101840.01dc3510@hplex1.hpl.hp.com> Date: Wed, 23 Jan 2002 10:44:58 -0800 Reply-To: Tim Kindberg From: Tim Kindberg Subject: Re: tags To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3C4EB689.26025.475BB20F@localhost> At 01:11 PM 1/23/2002 -0500, dan@dantobias.com wrote: >On 23 Jan 2002 at 9:18, Tim Kindberg wrote: > > > >I don't follow. How do you retrieve a digital resource > > >"from" a non-digital resource? > > > > You read the identifier with a sensor (e.g. a camera, barcode reader, ...) > > and send the identifier to a resolver, which looks it up and returns the > > URLs of one or more corresponding resources. > >In that case, the URI of the original offline resource is *not* being >dereferenced to an online resource that is "at" that URI; the >paradigm rather seems to be more that of hyperlinks, where various >online resources, at different URIs, can be "linked from" or >"associated with" the offline resource. The paradigm is like hyperlinks; I call them 'physical hyperlinks': instead of associating text (in a Web page) with a URI, we associate a physical object with a URI. That physical association, like a textual association, is significant at a human level but it's irrelevant to what happens in the system when the underlying URI gets resolved. The rest of what you say isn't clear but doesn't seem to make any important distinctions for me. The URI is resolved to a resource in exactly the same ways that any URI is resolved to a resource. >So, if I decide to assign URIs to each comic book in my collection, I >know that I can't actually retrieve the comic book by typing that >into a browser (or even scanning it from a bar code I've attached to >the plastic bag I'm storing the comic in), I think you're making an artificial distinction by setting up some type of Platonic resolution result and comparing it with other possible resolution results. It's not mathematically possible to 'know' anything a priori about the possible results of resolving an identifier except in some specified naming context. I can always construct a naming context that maps a given identifier to an (arbitrary) given result, and construct a 'browser' that acts as a client to that naming context. The fact that we use browsers of a certain type pointed to certain naming contexts is a convention driven by the application concerns of the times -- and they may change. Cheers, Tim. Tim Kindberg mobile systems and services lab hewlett-packard laboratories 1501 page mill road, ms 1u-17 palo alto ca 94304-1126 usa www.champignon.net/TimKindberg/ timothy@hpl.hp.com voice +1 650 857 5609 fax +1 650 857 2358 From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 14:01:04 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20779 for ; Wed, 23 Jan 2002 14:01:04 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA21105; Wed, 23 Jan 2002 13:59:38 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14105 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 13:59:35 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA21095 for ; Wed, 23 Jan 2002 13:59:33 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0NIrCj16525 for ; Wed, 23 Jan 2002 20:53:12 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 23 Jan 2002 20:53:30 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2VRZ8; Wed, 23 Jan 2002 20:53:26 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Wed, 23 Jan 2002 20:54:25 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: URx Questions To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <5.1.0.14.1.20020123085640.01d9d3c8@hplex1.hpl.hp.com> Content-Transfer-Encoding: 7bit On 2002-01-23 19:16, "ext Tim Kindberg" wrote: > At 12:21 PM 1/23/2002 +0200, Patrick Stickler wrote: >> With regards to temporal anchoring, 'tag:' seems to me to be >> too "mothering" and not general enough. > > You seem to have missed the point of tag. Without date qualification (or > something much more laborious), an entity that holds an authority name > could pollute the namespace of another entity that earlier held it. The > restriction is solely to guard against that. It is not exactly a > resource-hungry restriction. > > Of course, if you really want to, you could buy some DOIs instead (assuming > that _they_ will always be around). But we wanted to allow individuals and > small organisations to participate in naming at little or no cost -- that > includes those who possess only an email address (or domain name). Email > addresses are quite frequently given up as users change ISPs so the chances > of someone else getting the same authority name are not negligible. I fully understand the motivation and benefit of the tag date qualification, I just don't see that it has to be manditory. I think I gave sufficient examples to justify that view. And if a minting authority is truly concerned with absolute temporal uniqueness, they can either include date components in their hrn or use the UUID form. You seem to argue that because date qualification is not manditory, it's not possible, or that hrn's can't achieve temporal uniqueness without it. > >> And as has been pointed >> out, does not provide a form that garuntees against accidental >> collision within the same authority (e.g. UUID). > > > > >> I think that the IETF should *heavily* discourage, if not disallow >> dual registration of equivalent URI and URN NID schemes. > > I agree with you. Tag is not where it is by overall design but by where and > how we thought we could add value at the time. I think it's a mess that we > have both registrations going but 'the system' is a mess and I'm not yet > sure what to do to right our situation. I'm hoping that one or other > registration will reach a stage when the solution to the problem becomes > clear. It seems to me that the deciding criteria whether one registers a URN scheme as a top level URI scheme or a 'urn:' NID is whether one plans to use DDDS for global, transparent resolution. If so, then the NID makes sense. If not, then I see no reason to bother with NID and go with URI registration (though the latter is rather scary and laborious). Whether DDDS can be used or extended to support arbitrary URN schemes will be an interesting exercise. Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 14:07:39 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20910 for ; Wed, 23 Jan 2002 14:07:38 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA21365; Wed, 23 Jan 2002 14:05:49 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14168 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 14:05:46 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA21358 for ; Wed, 23 Jan 2002 14:05:44 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0NIxOj18004 for ; Wed, 23 Jan 2002 20:59:24 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 23 Jan 2002 20:59:41 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2VSJZ; Wed, 23 Jan 2002 20:59:41 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Wed, 23 Jan 2002 21:00:41 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: tags To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <5.1.0.14.1.20020123074050.03649280@hplex1.hpl.hp.com> Content-Transfer-Encoding: 7bit On 2002-01-23 19:18, "ext Tim Kindberg" wrote: > At 12:43 PM 1/23/02 +0200, Patrick Stickler wrote: > >> But why should the rest of the world also live with that >> restriction. Many folks *need* hierarchical identifiers. > > ? tag doesn't deny them that: whatever follows the may be > hierarchical. But since tag: is not a hierarchical URI scheme, one cannot use existing APIs and libraries that are able to recognize and parse hierarchical URIs. You then have to roll your own for the tag scheme, and any other scheme that "allows" you to have proprietary hierarchical syntax. >>> >>> I'm happy to let such communities develop their own standards but it's none >>> of my business. >> >> Then why are you commenting on the 'hrn:' scheme? > > I was talking about the tag scheme. But I'm also entitled to point out what > I believe to be deficiencies in other proposals. I thought that that what > this forum was for. Absolutely. Though on this point you appeared to be arguing that a general, hierarchical URI scheme was not needed. >>> One of our intended use models is indeed that people can attach tags to >>> physical entities but the point of doing so is for users to retrieve >>> digital resources from them >>> (http://www.hpl.hp.com/techreports/2001/HPL-2001-95.html). So I don't see >>> the difference. >> >> I don't follow. How do you retrieve a digital resource >> "from" a non-digital resource? > > You read the identifier with a sensor (e.g. a camera, barcode reader, ...) > and send the identifier to a resolver, which looks it up and returns the > URLs of one or more corresponding resources. I don't see how the entry method has anything to do with the nature or interpretation of the identifier. >> Do you mean e.g. a book which may both be printed and available >> in digital form? > > That would be one example. But one could associate (the identifier on) the > book with many other types of digital resource, depending upon the > application. Tag has nothing to say about the allowed types of binding. It appears that we are not talking about the same thing. You seem to be using the URI to retrieve metadata about the resource, not the resource. As with barcode or other entry methods, I don't see how that has anything to do with the nature of the URI itself. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 14:14:48 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21197 for ; Wed, 23 Jan 2002 14:14:48 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA21609; Wed, 23 Jan 2002 14:10:19 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14229 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 14:10:16 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA21602 for ; Wed, 23 Jan 2002 14:10:14 -0500 (EST) Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0NJ3sj18992 for ; Wed, 23 Jan 2002 21:03:54 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 23 Jan 2002 21:04:11 +0200 Received: from [10.114.130.183] ([10.114.130.183]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2VSSY; Wed, 23 Jan 2002 21:04:11 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Wed, 23 Jan 2002 21:05:10 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: tags To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <5.1.0.14.1.20020123101840.01dc3510@hplex1.hpl.hp.com> Content-Transfer-Encoding: 7bit On 2002-01-23 20:44, "ext Tim Kindberg" wrote: > At 01:11 PM 1/23/2002 -0500, dan@dantobias.com wrote: >> On 23 Jan 2002 at 9:18, Tim Kindberg wrote: >> >>>> I don't follow. How do you retrieve a digital resource >>>> "from" a non-digital resource? >>> >>> You read the identifier with a sensor (e.g. a camera, barcode reader, ...) >>> and send the identifier to a resolver, which looks it up and returns the >>> URLs of one or more corresponding resources. >> >> In that case, the URI of the original offline resource is *not* being >> dereferenced to an online resource that is "at" that URI; the >> paradigm rather seems to be more that of hyperlinks, where various >> online resources, at different URIs, can be "linked from" or >> "associated with" the offline resource. > > The paradigm is like hyperlinks; I call them 'physical hyperlinks': instead > of associating text (in a Web page) with a URI, we associate a physical > object with a URI. That physical association, like a textual association, > is significant at a human level but it's irrelevant to what happens in the > system when the underlying URI gets resolved. The rest of what you say > isn't clear but doesn't seem to make any important distinctions for me. The > URI is resolved to a resource in exactly the same ways that any URI is > resolved to a resource. The URI might be resolved to *a* resource -- namely a description of the resource, related resources, etc. -- but it does not seem to resolve to *the* resource itself. Thus, your URI is not a URN, but a URP of some sort, denoting a non-digital, non-retrievable resource about which you can say things. Eh? >> So, if I decide to assign URIs to each comic book in my collection, I >> know that I can't actually retrieve the comic book by typing that >> into a browser (or even scanning it from a bar code I've attached to >> the plastic bag I'm storing the comic in), > > I think you're making an artificial distinction by setting up some type of > Platonic resolution result and comparing it with other possible resolution > results. It's not mathematically possible to 'know' anything a priori about > the possible results of resolving an identifier except in some specified > naming context. I can always construct a naming context that maps a given > identifier to an (arbitrary) given result, and construct a 'browser' that > acts as a client to that naming context. The fact that we use browsers of a > certain type pointed to certain naming contexts is a convention driven by > the application concerns of the times -- and they may change. But it is precisely to capture the intent of the minting authority with regards to a resource that we need semantically distinct URI schemes, and for economy and order, URI classes. So that applications know what *should* happen, even if they can't know what *will* happen. Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 14:57:54 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22794 for ; Wed, 23 Jan 2002 14:57:54 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA23027; Wed, 23 Jan 2002 14:55:41 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14579 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 14:55:36 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from email8.net ([65.112.130.132]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA22943 for ; Wed, 23 Jan 2002 14:40:58 -0500 (EST) Received: from [65.112.130.130] (HELO dan) by email8.net (CommuniGate Pro SMTP 3.4.3) with ESMTP id 1538345; Wed, 23 Jan 2002 14:35:19 -0500 MIME-Version: 1.0 Priority: normal References: <5.1.0.14.1.20020123074050.03649280@hplex1.hpl.hp.com> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Message-ID: <3C4EC9F4.20997.47A79020@localhost> Date: Wed, 23 Jan 2002 14:34:28 -0500 Reply-To: dan@DANTOBIAS.COM From: dan@DANTOBIAS.COM Subject: Re: tags To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Content-Transfer-Encoding: 7BIT On 23 Jan 2002 at 21:00, Patrick Stickler wrote: > But since tag: is not a hierarchical URI scheme, one cannot use > existing APIs and libraries that are able to recognize and parse > hierarchical URIs. You then have to roll your own for the tag > scheme, and any other scheme that "allows" you to have proprietary > hierarchical syntax. To what purpose would one wish to have software automatically parse out the hierarchical levels of a non-URL URI? Even with URLs, with their specified hierarchy, you can't always reach a useful resource by simply paring off levels from the hierarchy, though users sometimes try it in their attempts to get around sites with poor navigation structures. (There's a Bugzilla entry for the Mozilla browser that suggests adding an "Up" button that does this hierarchy slicing, with much debate over whether this is desirable or not -- many seem to think power users will find it useful but novices will get too confused.) While this has some (intermittent) utility for URL navigation, what purpose would it serve for other URI types? In general, I'd like to see more detailed description in the proposals for new URI schemes and URN namespaces of just what purposes these schemes can be used for. There are lots of intriguing ideas for namespaces in these proposals, but they tend to be rather light on specifics about just what practical use they are. Some concrete examples of uses to which they may be put would be helpful. -- Dan Dan's Web Tips: http://www.dantobias.com/webtips/ From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 15:06:19 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23141 for ; Wed, 23 Jan 2002 15:06:19 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA23197; Wed, 23 Jan 2002 15:04:14 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14624 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 15:04:11 -0500 Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA23190 for ; Wed, 23 Jan 2002 15:04:09 -0500 (EST) Received: from hplns3.hpl.hp.com (hplns3.hpl.hp.com [15.0.48.4]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id LAA02775; Wed, 23 Jan 2002 11:58:06 -0800 (PST) Received: from timpc.hpl.hp.com (timpc.hpl.hp.com [15.4.92.160]) by hplns3.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id g0NJw3G07522; Wed, 23 Jan 2002 11:58:03 -0800 (PST) X-Sender: timothy@hplex1.hpl.hp.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.1.20020123074050.03649280@hplex1.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: Tim Kindberg Message-ID: <5.1.0.14.1.20020123113626.01e02060@hplex1.hpl.hp.com> Date: Wed, 23 Jan 2002 11:58:00 -0800 Reply-To: Tim Kindberg From: Tim Kindberg Subject: Re: tags To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: At 09:00 PM 1/23/2002 +0200, Patrick Stickler wrote: >But since tag: is not a hierarchical URI scheme, one cannot use >existing APIs and libraries that are able to recognize and parse >hierarchical URIs. You then have to roll your own for the tag >scheme, and any other scheme that "allows" you to have proprietary >hierarchical syntax. I have some sympathy with the idea that we should have specified tags to be of the form, for example, tag:timothy@hpl.hp.com/2002/01/23/whatever.... ... for the sake of syntactic uniformity -- while keeping all the other properties of tags. But it wouldn't buy us anything else because tags are only ever compared or resolved in their entirety. And I still don't agree with you about the mandatory status of dates, for the same reasons as before. > >> > >> I don't follow. How do you retrieve a digital resource > >> "from" a non-digital resource? > > > > You read the identifier with a sensor (e.g. a camera, barcode reader, ...) > > and send the identifier to a resolver, which looks it up and returns the > > URLs of one or more corresponding resources. > >I don't see how the entry method has anything to do >with the nature or interpretation of the identifier. Hmmm. I answered your question exactly but now I'm to be upbraided because it wasn't the question you meant :). > >> Do you mean e.g. a book which may both be printed and available > >> in digital form? > > > > That would be one example. But one could associate (the identifier on) the > > book with many other types of digital resource, depending upon the > > application. Tag has nothing to say about the allowed types of binding. > >It appears that we are not talking about the same thing. > >You seem to be using the URI to retrieve metadata about >the resource, not the resource. As with barcode or other >entry methods, I don't see how that has anything to do >with the nature of the URI itself. I'm philosophically opposed to the notion that there is such a thing as "the" resource. There are names; there are naming contexts that map names to other names or to resources; and there are resources (addressible functions). "The" resource that you speak of can only mean "the resource that this name maps to in this context". So which context are you talking about -- the one that gives you or your community the type or status of answer you want? Or the one that the minting authority wants to associate with the identifier? I agree that I would like my client to be able to determine the minting authority's resolver for a name that it minted, in case I wanted its resource. There are several ways of achieving that, essentially by agreement to a 'root' context that maps naming authorities to resolver addresses. But the minting authority's context is just another naming context. Cheers, Tim. Tim Kindberg mobile systems and services lab hewlett-packard laboratories 1501 page mill road, ms 1u-17 palo alto ca 94304-1126 usa www.champignon.net/TimKindberg/ timothy@hpl.hp.com voice +1 650 857 5609 fax +1 650 857 2358 From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 23 16:03:54 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25327 for ; Wed, 23 Jan 2002 16:03:54 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA24143; Wed, 23 Jan 2002 16:01:33 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14837 for URN-IETF@LISTS.NETSOL.COM; Wed, 23 Jan 2002 16:01:28 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA24136 for ; Wed, 23 Jan 2002 16:01:26 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0NKtPt23983 for ; Wed, 23 Jan 2002 22:55:25 +0200 (EET) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 23 Jan 2002 22:55:22 +0200 Received: from [10.114.130.183] (tr-adsl-dhcp-130183.ntc.nokia.com [10.114.130.183]) by esebh01nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id DDBYGM1H; Wed, 23 Jan 2002 22:54:59 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Wed, 23 Jan 2002 22:55:58 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: tags To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3C4EC9F4.20997.47A79020@localhost> Content-Transfer-Encoding: 7bit I am working on a paper that outlines the URI schemes based on their potential applications, and hope to have that done by the end of February (unfortunately, I have to fit it in and around alot of other, higher priority work). But when it gets near final draft stage, I'll post it here for folks to rip up (er, comment on ;-) Cheers, Patrick On 2002-01-23 21:34, "ext dan@dantobias.com" wrote: > On 23 Jan 2002 at 21:00, Patrick Stickler wrote: > >> But since tag: is not a hierarchical URI scheme, one cannot use >> existing APIs and libraries that are able to recognize and parse >> hierarchical URIs. You then have to roll your own for the tag >> scheme, and any other scheme that "allows" you to have proprietary >> hierarchical syntax. > > To what purpose would one wish to have software automatically parse > out the hierarchical levels of a non-URL URI? Even with URLs, with > their specified hierarchy, you can't always reach a useful resource > by simply paring off levels from the hierarchy, though users > sometimes try it in their attempts to get around sites with poor > navigation structures. (There's a Bugzilla entry for the Mozilla > browser that suggests adding an "Up" button that does this hierarchy > slicing, with much debate over whether this is desirable or not -- > many seem to think power users will find it useful but novices will > get too confused.) While this has some (intermittent) utility for > URL navigation, what purpose would it serve for other URI types? > > In general, I'd like to see more detailed description in the > proposals for new URI schemes and URN namespaces of just what > purposes these schemes can be used for. There are lots of intriguing > ideas for namespaces in these proposals, but they tend to be rather > light on specifics about just what practical use they are. Some > concrete examples of uses to which they may be put would be helpful. > > -- > Dan > Dan's Web Tips: http://www.dantobias.com/webtips/ > > > -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Fri Jan 25 06:08:04 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28592 for ; Fri, 25 Jan 2002 06:08:04 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA04099; Fri, 25 Jan 2002 06:06:11 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15827 for URN-IETF@LISTS.NETSOL.COM; Fri, 25 Jan 2002 06:05:25 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA04087 for ; Fri, 25 Jan 2002 06:05:23 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0PAxNt05111 for ; Fri, 25 Jan 2002 12:59:23 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Jan 2002 12:59:18 +0200 Received: from [172.21.193.136] ([172.21.193.136]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2YBVA; Fri, 25 Jan 2002 12:59:16 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Fri, 25 Jan 2002 12:13:09 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: The Neo-Classical View of URI Classification To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit This document outlines what I am calling the "Neo-Classical View" of URI Classification, which is a revised version of that outlined in draft-pstickler-uri-taxonomy-00 motivated by recent discussions on this list and elsewhere. -- Background: Based on both official and unofficial publications and discussions, my understanding of the classical view is as follows: Variant 1: Digital | Non-Digital | <--URL--------> | | <--URN-------------------------> | Variant 2: Digital | Non-Digital | <--URL-------------------------> | <--URN-------------------------> | These two variants appear to have co-existed from early on in the history of the internet, if not from the very beginning. Some may argue to the contrary, that only variant 2 has existed, but common confusion and consternation by a non-trivial segment of the web population regarding URLs which do not resolve to anything (because they denote non-digital, possibly abstract, resources) is sufficient to establish the existence of the first variant. The first two variants were, as a result of much debate, merged into the contemporary view, which really is just the removal of any distinction between URI classes in terms of resolution to digital versus non-digital resources; i.e.: Digital | Non-Digital | <--URI-------------------------> | Thus, the prior debate was not really resolved, but simply abandoned. Furthermore, the contemporary view, as did the classical view before it, totally disregards the notion of a non-resolvable URI, correlating to a kind of constant, i.e. the URP. -- My own recent proposal, in draft-pstickler-uri-taxonomy-00, can be considered a third variant of the classical view, which admittedly is not entirely compatible with either of the above two variants, due to the restriction on URNs to denote only digital resources: Variant 3: Digital | Non-Digital | <--URL--------> | | <--URN--------> | | |<--URP--------> | -- The Neo-Classical View: In light of the recent discussions regarding the nature of URNs and their denotation of digital versus non-digital resources, I would like to offer a revised model for URI classification which allows for URNs to denote either digital or non-digital (accessible or non-accessible) resources. I will call this new view the "Neo-Classical View": Digital | Non-Digital | <--URL--------> | | <--URN-------------------------> | |<--URP--------> | Clearly, this is an adoption and extension of the first variant of the classical view -- but the criteria for differentiation between these URI classes is different than traditionally applied to the variants of the classicial view, and thus may be more palatable to proponents of the second variant of the classical view. A common theme or topic in the debates between the first two variants of the classical view was the notion of name versus location, such that e.g. a URL denotes a location and therefore must resolve to a resource. However, in draft-pstickler-uri-taxonomy-00, I propose a different set of criteria for differentiation which I feel is better suited than the name vs. location distinction. The following table shows the differentiation of URI Classes per the Neo-Classical View based on the criteria of resolvability to digital resource and indication of agencies/authorities in the URI itself for scheme definition, minting, and resolution: ------------------------- | URI | |-----------------------| | | | URP | | | |-----------| | URL | URN | URT | URV | |------------------------------|-----|-----|-----|-----| | Resolves to Digital Resource | * | o | x | x | |------------------------------|-----|-----|-----|-----| | Scheme Authority in URI | * | * | * | * | |------------------------------|-----|-----|-----|-----| | Minting Authority in URI | * | * | * | x | |------------------------------|-----|-----|-----|-----| | Resolution Agency in URI | * | x | x | x | |------------------------------|-----|-----|-----|-----| where * = required o = allowed x = disallowed Note that the compromise is the presence of 'o' rather than '*' in the first row for URN. My previous variant of the classical view disallowed URNs from denoting non-digital resources. Because knowledge about the binding of URNs to URLs must be defined on an instance by instance basis, it is also reasonable to provide the clarification of resolvability to digital resource to be specified on an instance by instance basis -- i.e. it is no less economical in the case of URN interpretation, which always requires instance specific knowledge. However, by requiring URLs to resolve to digital resources and disallowing URPs from resolving to digital resources we are able to achieve a significant economy in definition, being able to assume such an interpretation for all instances of each type, without recourse to definition on an instance by instance basis. Since URNs tend to denote either digital resources which are diligently managed and/or non-digital resources which are widely significant and fairly static, this requirement of instance by instance definition is not untenable. In contrast, as URLs and URPs may be minimally managed and/or highly transient identifiers, maximal economy in their interpretation is highly desirable. It should be noted that, although the URN class is agnostic about whether a given instance does or does not resolve to a digital resource, a subclass of URN or a URN scheme may itself make resolution to a digital resource a requirement. Neither 'urn:', 'tag:', nor "hrn:' assert such a requirement (the I-D for the latter will be revised to reflect this). The above refinements corresponding to the Neo-Classicial view will be reflected in the next revision of draft-pstickler-uri-taxonomy-00. Further discussion is, of course, both anticipated and welcomed. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Fri Jan 25 06:10:26 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28660 for ; Fri, 25 Jan 2002 06:10:25 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA04125; Fri, 25 Jan 2002 06:09:21 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15833 for URN-IETF@LISTS.NETSOL.COM; Fri, 25 Jan 2002 06:09:18 -0500 Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA04093 for ; Fri, 25 Jan 2002 06:05:47 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0PAxrn17445 for ; Fri, 25 Jan 2002 12:59:53 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Jan 2002 12:59:40 +0200 Received: from [172.21.193.136] ([172.21.193.136]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2YBVY; Fri, 25 Jan 2002 12:59:39 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Fri, 25 Jan 2002 12:25:06 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: tags To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <5.1.0.14.1.20020123113626.01e02060@hplex1.hpl.hp.com> Content-Transfer-Encoding: 7bit On 2002-01-23 21:58, "ext Tim Kindberg" wrote: > I'm philosophically opposed to the notion that there is such a thing as > "the" resource. There are names; there are naming contexts that map names > to other names or to resources; and there are resources (addressible > functions). "The" resource that you speak of can only mean "the resource > that this name maps to in this context". Whether or not several names, possibly contextual, correspond to the same "thing" in the universe does not mean that a given name does not correspond to one and only one thing. Names may only be valid or interpretable within a given context, but I do not agree that the same name in different contexts can correspond to different "things". One may use a name as a referent in various operations, such as retrieving information *about* that thing, but that information retrieved is not *the* thing itself. A name identifies a resource. A resource may either itself be retrieved or used as the context or focus of the retrieval of other resources. I think this distinction is fundamental to the expected and required behavior of the web and semantic web. A name cannot in one context identify a resource and then in some other context directly identify some other resource, even if the other resource is related in some way to the first. Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Fri Jan 25 11:16:30 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06367 for ; Fri, 25 Jan 2002 11:16:30 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA06178; Fri, 25 Jan 2002 11:13:11 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16176 for URN-IETF@LISTS.NETSOL.COM; Fri, 25 Jan 2002 11:12:54 -0500 Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA06171 for ; Fri, 25 Jan 2002 11:12:53 -0500 (EST) Received: from hplns3.hpl.hp.com (hplns3.hpl.hp.com [15.0.48.4]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id IAA10374; Fri, 25 Jan 2002 08:06:48 -0800 (PST) Received: from tims-omnibook.hpl.hp.com (pal1nai163039.nsr.hp.com [15.244.163.39]) by hplns3.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id g0PG6kh17103; Fri, 25 Jan 2002 08:06:47 -0800 (PST) X-Sender: timothy@hplex1.hpl.hp.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.1.20020123113626.01e02060@hplex1.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: Tim Kindberg Message-ID: <5.1.0.14.1.20020125074940.03e80620@hplex1.hpl.hp.com> Date: Fri, 25 Jan 2002 08:13:37 -0800 Reply-To: Tim Kindberg From: Tim Kindberg Subject: Re: tags To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: At 12:25 PM 1/25/02 +0200, Patrick Stickler wrote: >Names may only be valid or interpretable within a given context, but >I do not agree that the same name in different contexts can correspond >to different "things". So /etc/passwd is guaranteed to be the same file on all UNIX computers? So we have to give up the independence of bindings of names like 192.168.0.*? If you want the Web to be different then you have to define the property of the Web that makes it so. I believe that we do need a way of getting a default binding -- a mechanism whereby software can automatically get the address of the resource bound by the name's minting authority. But the software that I have as my client should equally be capable of using alternative naming contexts to reach alternative resources. Let's have a market of naming contexts just as we have a market of web sites. I shouldn't have to have new software to take advantage of a new naming context. E.g. imagine that a film has a globally/temporally unique name; now imagine all the sites/naming-contexts you might want to get resources from, using that same identifier. Even if you insist on saying that those other resources are likely to be 'metadata' about the minting authority's resource, they're still separately managed resources. Tim. Tim Kindberg mobile systems and services lab hewlett-packard laboratories 1501 page mill road, ms 1u-17 palo alto ca 94304-1126 usa www.champignon.net/TimKindberg/ timothy@hpl.hp.com voice +1 650 857 5609 fax +1 650 857 2358 From owner-urn-ietf@LISTS.NETSOL.COM Sun Jan 27 13:40:27 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02064 for ; Sun, 27 Jan 2002 13:40:27 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA17037; Sun, 27 Jan 2002 13:37:51 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16825 for URN-IETF@LISTS.NETSOL.COM; Sun, 27 Jan 2002 13:36:51 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from toro.w3.mag.keio.ac.jp (postfix@toro.w3.mag.keio.ac.jp [133.27.228.201]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA16853 for ; Sun, 27 Jan 2002 12:46:58 -0500 (EST) Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 96748E32; Mon, 28 Jan 2002 02:40:43 +0900 (JST) X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J References: <5.1.0.14.1.20020123113626.01e02060@hplex1.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.0.58.J.20020127222503.02dedef8@localhost> Date: Sun, 27 Jan 2002 22:34:02 +0900 Reply-To: Martin Duerst From: Martin Duerst Subject: Re: tags To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: At 12:25 02/01/25 +0200, Patrick Stickler wrote: >A name cannot in one context identify a resource and then in >some other context directly identify some other resource, even >if the other resource is related in some way to the first. So what exactly is the resource in a web site that's language- negotiated (e.g. set your browser's preference to have Japanese and French higher than English, and browse through the Apache documentation). The resource is e.g. 'documentation of module FOO' independent of language. It is NOT some sequence of characters/bytes, because there is no single entity to uniquely and consistently represent this resource. Resolving the resource doesn't give you something you can call 'the resource', it's just one possible variant. The resource only exists in our imagination. How does that fit into your model? Regards, Martin. From owner-urn-ietf@LISTS.NETSOL.COM Mon Jan 28 06:59:10 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22728 for ; Mon, 28 Jan 2002 06:59:10 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA21304; Mon, 28 Jan 2002 06:56:44 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17242 for URN-IETF@LISTS.NETSOL.COM; Mon, 28 Jan 2002 06:56:21 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA21297 for ; Mon, 28 Jan 2002 06:56:17 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0SBntj26744 for ; Mon, 28 Jan 2002 13:49:55 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 28 Jan 2002 13:50:12 +0200 Received: from [172.22.43.91] (trd043-91.research.nokia.com [172.22.43.91]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0Z41TRF; Mon, 28 Jan 2002 13:50:12 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: Patrick Stickler Message-ID: Date: Mon, 28 Jan 2002 13:51:18 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: tags To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <5.1.0.14.1.20020125074940.03e80620@hplex1.hpl.hp.com> Content-Transfer-Encoding: 7bit On 2002-01-25 18:13, "ext Tim Kindberg" wrote: > At 12:25 PM 1/25/02 +0200, Patrick Stickler wrote: > >> Names may only be valid or interpretable within a given context, but >> I do not agree that the same name in different contexts can correspond >> to different "things". > > So /etc/passwd is guaranteed to be the same file on all UNIX computers? So > we have to give up the independence of bindings of names like 192.168.0.*? > My apologies, I was thinking URI and wrote "name". My argument was that URIs are global names with consistent meaning. A URI cannot mean different things in different contexts, as the intended scope of URIs is to be globally consistent. Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Jan 28 07:06:12 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22847 for ; Mon, 28 Jan 2002 07:06:12 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA21467; Mon, 28 Jan 2002 07:04:54 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17239 for URN-IETF@LISTS.NETSOL.COM; Mon, 28 Jan 2002 07:04:51 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from smtprelay6.dc2.adelphia.net (smtprelay6.dc2.adelphia.net [64.8.50.38]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA05591 for ; Fri, 25 Jan 2002 08:39:17 -0500 (EST) Received: from 21afr ([24.51.220.230]) by smtprelay6.dc2.adelphia.net (Netscape Messaging Server 4.15) with ESMTP id GQHXMK00.D0V; Fri, 25 Jan 2002 08:32:44 -0500 MIME-Version: 1.0 Priority: normal X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Message-ID: <3C511819.11465.1D7BFD5B@localhost> Date: Fri, 25 Jan 2002 08:32:25 -0500 Reply-To: "Daniel R. Tobias" From: "Daniel R. Tobias" Subject: Re: The Neo-Classical View of URI Classification To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Content-Transfer-Encoding: 7BIT > These two variants appear to have co-existed from early on in the > history of the internet, if not from the very beginning. Some may You should say "the history of the Web" instead of "the history of the Internet" (Internet and Web should both be capitalized here because they're being used as proper names); the history of the Internet goes back 20 years before Tim Berners-Lee's first paper proposing the creation of the Web. The Internet started as the ARPAnet in 1969, and the term "Internet" was in common use (among academic communities at least) by the mid 1980s, well before URIs of any form existed. > Digital | Non-Digital > | > <--URL--------> | > | > <--URN-------------------------> > | > |<--URP--------> But since URPs are supposed to be non-digital, where does that place the "data:" scheme, which in fact consists of digital data -- not "resolved" to a digital resource, because the data is contained directly within the URI (so you're correct in classifying that scheme as a URP because it's effectively a constant rather than an address), but it's still data of a digital form (and can hence be used in contexts such as the IMG tag that expect digital data). This makes "data:" of a different nature than other URIs that are intended to denote a non-digital thing "in the real world" (e.g., a dog, or a can of beans). Those URIs would be meaningless to place within an IMG tag, as they don't represent a *digital picture* of a dog or a can of beans, but rather the objects themselves. Maybe you need still more UR* acronyms to make this significant distinction? -- == Dan == Dan's Web Tips: http://www.dantobias.com/webtips/ Dan's Domain Site: http://domains.dantobias.com/ From owner-urn-ietf@LISTS.NETSOL.COM Mon Jan 28 07:39:26 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23187 for ; Mon, 28 Jan 2002 07:39:26 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA22319; Mon, 28 Jan 2002 07:38:15 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17483 for URN-IETF@LISTS.NETSOL.COM; Mon, 28 Jan 2002 07:38:11 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA22312 for ; Mon, 28 Jan 2002 07:38:09 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0SCVlj14658 for ; Mon, 28 Jan 2002 14:31:47 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 28 Jan 2002 14:32:05 +0200 Received: from [172.22.43.91] ([172.22.43.91]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 28 Jan 2002 14:32:05 +0200 User-Agent: Microsoft-Entourage/10.0.0.1309 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Jan 2002 12:32:05.0847 (UTC) FILETIME=[CBA58E70:01C1A7F7] Approved-By: Patrick Stickler Message-ID: Date: Mon, 28 Jan 2002 14:33:10 +0200 Reply-To: Patrick Stickler From: Patrick Stickler Subject: Re: The Neo-Classical View of URI Classification To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3C511819.11465.1D7BFD5B@localhost> Content-Transfer-Encoding: 7bit On 2002-01-25 15:32, "ext Daniel R. Tobias" wrote: >> These two variants appear to have co-existed from early on in the >> history of the internet, if not from the very beginning. Some may > > You should say "the history of the Web" instead of "the history of > the Internet" (Internet and Web should both be capitalized here > because they're being used as proper names); the history of the > Internet goes back 20 years before Tim Berners-Lee's first paper > proposing the creation of the Web. The Internet started as the > ARPAnet in 1969, and the term "Internet" was in common use (among > academic communities at least) by the mid 1980s, well before URIs of > any form existed. Thank you. I stand corrected. Yes, 'Web' not 'Internet'. >> Digital | Non-Digital >> | >> <--URL--------> | >> | >> <--URN-------------------------> >> | >> |<--URP--------> > > But since URPs are supposed to be non-digital, where does that place > the "data:" scheme, which in fact consists of digital data -- not > "resolved" to a digital resource, because the data is contained > directly within the URI (so you're correct in classifying that scheme > as a URP because it's effectively a constant rather than an address), > but it's still data of a digital form (and can hence be used in > contexts such as the IMG tag that expect digital data). > > This makes "data:" of a different nature than other URIs that are > intended to denote a non-digital thing "in the real world" (e.g., a > dog, or a can of beans). Those URIs would be meaningless to place > within an IMG tag, as they don't represent a *digital picture* of a > dog or a can of beans, but rather the objects themselves. > > Maybe you need still more UR* acronyms to make this significant > distinction? No. It's simply a bad choice of diagram labels. "Digital" means resolvable to a digital resource. "Non-Digital" means not resolvable to a digital resource. This was clearer in the matrix, and also I think (hope) in the prose, but yes, the choice of labels for the diagrams is confusing. I should probably have used "resolvable" versus "non-resolvable", which more accurately (I hope) expresses the distinction. I.e. >> Resolvable | Non-Resolvable >> | >> <--URL--------> | >> | >> <--URN-------------------------> >> | >> |<--URP--------> Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com