idnits 2.17.1 draft-yeoh-tldhere-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 127 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Document expiration date: 13 May 2001 L. Yeoh 4 Top Level DNS Name for addressing by physical context 5 7 INTERNET-DRAFT 9 This document is an Internet-Draft and is in full conformance 10 with all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Status of this Memo 31 Distribution of this memo is unlimited. 33 Copyright Notice 35 Copyright (C) The Internet Society (2000). All Rights Reserved. 37 Abstract 39 This document proposes the reservation of a special use TLD to allow a 40 more convenient addressing of devices by general physical location or 41 context. 43 1. Introduction 45 As wireless networking and devices become more common there may be a need 46 for a convenient way to address hosts by physical location or context, 47 especially when the users themselves are using mobile or wearable devices. 49 A step towards this could be by reserving a special public use TLD (.here in 50 the examples ). Then this TLD can be independently hosted at various 51 locations, so that each resulting .here domain falls under the context of 52 that particular location. For a similar concept see RFC1918 [RFC1918]. 54 2. Example usage of .here TLD 56 As an example a user could obtain a list of registered devices in each 57 particular room or building by visiting https://all.here/ or perhaps just 58 https://here/. Other forms could include https://who.here/ and 59 https://what.here/ 61 Say if the user wishes to control an air conditioner in a room, the user 62 could visit https://airconditioner.here/ for the control page. The user 63 could also "bookmark" popular settings such as 64 https://airconditioner.here/settemp?celsius=25 and use it from room to room 65 (assuming the air conditioners accept the same parameters). 67 Users of wearable devices could also address and access each other in a 68 similar manner after registering with the location - e.g. 69 https://lyeoh.here/sendobjectform or https://somebody.here/getobject?id=12345 71 Registration with an area could be done with DHCP [RFC2131] and dynamic DNS. 73 3. Various Considerations 75 Users could get the wrong address depending on how the default domain 76 search is implemented - e.g. xxxx.here first, then xxxx.mydomain.com or 77 vice versa. Also, it should be assumed that parties controlling the 78 physical location can attempt to spoof or subvert communications. 80 Specifying .here. does not guarantee locality. Users may inadvertently or 81 intentionally access devices at a different physical location. 83 Third parties could reserve a similar TLD (e.g. .her.) in order to catch 84 typographical errors or unsuspecting users. As .her. and .he. may well 85 become future TLDs, perhaps a less vulnerable name than .here should be 86 used instead. A less elegant alternative is to also reserve the typos, but 87 the Gere's (e.g. Richard) of the world may protest. 89 The .here TLD has already been reserved by a member of the ORSC 90 (www.open-rsc.org). So to avoid conflict another TLD may have to be chosen, 91 giving due consideration to the various alternative root zones. 92 It seems that .local or .loc could be used but at risk of confusion with 93 .localhost [RFC2606]. 95 4. References 97 [RFC2606] D. Eastlake and A. Panitz, "Reserved Top Level DNS Names", 98 RFC2606, June 1999. 100 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", March 1997. 102 [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, 103 E. Lear, "Address Allocation for Private Internets", February 1996. 105 5. Author's Address 107 Lincoln Yeoh 108 20, Jalan 225 109 46100 Petaling Jaya 110 Malaysia 112 Phone: +60 3 7874 3422 113 EMail: lyeoh@pop.jaring.my 115 Document expiration date: 13 May 2001