idnits 2.17.1 draft-mealling-pin-urn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 3) being 68 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 52 has weird spacing: '...ntained appli...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 26, 2000) is 8613 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 170, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (ref. '1') (Obsoleted by RFC 8141) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M.M. Mealling 2 Internet-Draft Network Solutions, Inc. 3 Expires: March 27, 2001 September 26, 2000 5 The Network Solutions Personal Internet Name (PIN): A URN Namespace 6 for People and Organizations 7 draft-mealling-pin-urn-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is NOT offered in accordance 12 with Section 10 of RFC2026, and the author does not provide the IETF 13 with any rights other than to publish as an Internet-Draft. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 27, 2001. 33 Abstract 35 This document describes a URN namespace that is engineered by 36 Network Solutions, Inc for naming people and organizations. 38 1. Introduction 40 In many cases Network Solutions' maintained directory applications 41 require some unique and persistent way to talk about an individual 42 or organization. For example, white pages style services need to 43 determine if one entry is distinct from another even if some of the 44 data happens to be the same. Also, e-commerce authentication 45 mechanisms needs to identify a user and/or company uniquely and 46 possibly over large spans of time. In many cases a customer 47 relationship can last several decades. Such long term customer 48 relationships can outlast any specific email address, Internet 49 service provider, surname, or possibly even the DNS itself. 51 The intent for these applications is that they be used and 52 integrated into other, non-NSI maintained applications in much the 53 same way that domain-names that exist in Network Solution's database 54 are primarily used in application that Network Solutions is _not_ 55 involved in. In much the same way that ISBNs are maintained by 56 specific entities but used in widely varrying applications, NSI's 57 PIN namespace is intended to be used in many applications where 58 there is a need for a well maintained identifier that names a person 59 or organization. 61 A URN namespace is uniquely suited to solve the persistent 62 identification needs of these applications since they are also 63 required to be unique and persistent. . The availability of a 64 standardized resolution mechanism makes it possible for other 65 applications to reference and resolve PIN URNs in their own systems 66 in an open, non-proprietary way. 68 This namespace specification is for a formal namespace. 70 2. Specification Template 72 Namespace ID: 74 "pin" requested. 76 Registration Information: 78 Registration Version Number: 1 79 Registration Date: 2000-09-30 81 Declared registrant of the namespace: 83 Network Solutions 84 505 Huntmar Park Drive 85 Herndon, VA 22070 87 Declaration of structure: 89 The structure of the NSS is a flat space of alphanumeric 90 characters which have no knowable structure outside of the 91 context of Network Solutions internal resolver. Future changes 92 to the assignement methods may allow others to assign 93 sub-spaces of the flat namesapce but again, this knowledge is 94 only valid internally and should never be inferred or relied 95 upon externally. 97 Relevant ancillary documentation: 99 None 101 Identifier uniqueness considerations: 103 Identifiers are assigned by Network Solutions proprietary 104 registration system in a way that guarantees uniqueness. At 105 this time the algorithm is to iterate from the last assigned 106 number by some positive integer. In the future this algorithm 107 may change to incorporate a full range of alphanumeric 108 elements. In either case, the system will compare the newly 109 created identifier with all of the previous ones to ensure 110 that it has not already been assigned. 112 Identifier persistence considerations: 114 The assignment process guarantees that names are not reassigned 115 and that the binding between the name and the person or 116 organization is permanent, regardless of any personal name 117 changes, corporate restructuring, death or dissoluion.. 119 Process of identifier assignment: 121 Names are granted via Network Solutions proprietary registration 122 procedures. 124 Process of identifier resolution: 126 PIN URNs are resolved via URN resolvers run by Network 127 Solutions. Since a PIN URN identifies a person or 128 organization, resolving a PIN URN will only be able to return 129 information from an electronic proxy that is merely a 130 representation of the actual person or organization being 131 named. 133 Rules for Lexical Equivalence: 135 The entire URN is case-insensitive. 137 Conformance with URN Syntax: 139 There are no additional characters reserved. 141 Validation mechanism: 143 None additional to resolution specified 145 Scope: 147 Global 149 3. Examples 151 The following examples are not guaranteed to be real. They are 152 listed for pedagogical reasons only. 154 URN:pin:bs4321234 155 URN:pin:324kj5hkj45 156 URN:pin:mm2136 158 4. Security Considerations 160 Since the URNs in this namespace are opaque there are no additional 161 security considerations other than those normally associated with 162 the use and resolution of URNs in general. 164 It is noted however that attempting to resolve a PIN URN through a 165 resolver other than the one provided by Network Solution is error 166 prone. In any case it is not considered authoritative. 168 References 170 [1] Moats, R., "URN Syntax", RFC 2141, May 1997. 172 Author's Address 174 Michael Mealling 175 Network Solutions, Inc. 176 505 Huntmar Park Drive 177 Herndon, VA 22070 178 US 180 Phone: +1 770 935 5492 181 EMail: michaelm@netsol.com 182 URI: http://www.netsol.com