idnits 2.17.1 draft-ietf-trade-srv-higher-services-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (October 2002) is 7864 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: 'RFC 2782' is defined on line 155, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Donald E. Eastlake 3rd 2 Motorola 3 Expires April 2003 October 2002 5 DNS SRV Location of Higher Level Services 6 8 Status of this Memo 10 Distribution of this document is unlimited. Comments should be sent 11 to the authors or the IETF TRADE working group . 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026. Internet-Drafts are 16 working documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." The list 24 of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 26 Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) 2002, The Internet Society. All Rights Reserved. 33 Abstract 35 DNS naming conventions specified in RFC 2782 are extended to higher 36 level services and a registry created for the tokens used. 38 Table of Contents 40 Status of this Memo........................................1 41 Copyright Notice...........................................1 42 Abstract...................................................1 43 Table of Contents..........................................2 45 1. Introduction............................................3 46 2. Specification...........................................3 47 3. International Considerations............................4 48 4. IANA Considerations.....................................4 49 5. Security Considerations.................................4 51 Normative References.......................................5 52 Informative References.....................................5 54 Authors Address............................................6 56 Full Copyright Statement...................................7 57 File name and Expiration...................................7 59 1. Introduction 61 RFC 2782 specifies a DNS SRV Resource Record for the location of 62 services. In addition, it provides a DNS naming convention for the 63 DNS nodes at which such SRV RRs are stored. That is the form 64 _Service._Proto.name.example 65 as the name of the DNS node at which SRV RRs would be stored for 66 obtaining the "Service" from "name.example". 68 While there are a variety of means for locating higher level 69 application services, some such services may wish to use the SRV RR. 70 Such higher level services would, typically, be provided over the 71 sorts of services that the RFC 2782 syntax is designed to speicfy. 72 This document extends that syntax so that higher level protocols can 73 be specified. 75 2. Specification 77 SRV RRs can be stored at nodes with names of the following form 78 _Higher._Service._Proto.name.example 79 For example 80 _iotp._http._tcp.example.net. 82 The definition of the "_Proto" DNS label is the same as in RFC 2782. 84 For the use described in this document, the "_Service" DNS label is a 85 port specifying token registered with IANA in Assigned Numbers (such 86 as http or ldap), prefixed with an underscore character. 88 The DNS label "_Higher" is a token consisting from 2 to 12 ASCII 89 letters and digits, registered as provided in Section 4 below, and 90 prefixed with an underscore character. 92 Higher level protocols sometimes have a number of services. To 93 minimize the burden on the registration authority and maximize 94 convenience to the protocol specifier, "Higher" may also consist of a 95 token as registered hereunder followed by a hyphen character, 96 followed by any characters allowed in connection with location of the 97 higher level service. For example 98 _xkms-xkiss-soap._http._tcp.example.org. 100 Neither this specification nor registration hereunder is intended to 101 imply over what services or protocols a higher level service can be 102 used. Such limitations are specified in connection with that higher 103 level service. For example, you need to look at the IOTP related 104 specification for any information as to whether 105 _iotp._smtp._sctp.foo.example 106 could be useful. 108 Due to the case insensitive nature of DNS labels [RFC 1035], all of 109 "_Higher", "_Service", and "_Proto" are case insensitive. 111 3. International Considerations 113 The fully qualified DNS names discussed in this document and the 114 Higher, Service, and Proto tokens appearing therein will normally be 115 program generated and not seen by users. Thus no internationalization 116 provisions are made. 118 4. IANA Considerations 120 Upon approval by the IESG of the document, IANA will maintain a 121 registry of higher level application designating tokens for use as 122 specified in Section 2 above. The initial contents of the registry 123 will be the two tokens 125 IOTP - [RFC 2801] 126 XKMS - [XML XKMS] 128 The requirement for the registration of additional tokens is the 129 documentation of each in an RFC or a similar free publicly accessible 130 and reproducable document. To minimize the burden on the registry 131 maintainer and maximize interoperability and convenience for the 132 protocol specifier, such registration is to be taken as automatically 133 incorporating later free publicly accessible and reproducable 134 versions or amendments to the initial registration basis document by 135 the entity with change control over the higher level service 136 specification. To the extend reasonable, only a single token should 137 be registered for a family of related higher level protocols or 138 protocol versions that are under common control. The mechanism 139 specified in Section 2 for extending such a token should be used, 140 where needed, to distinguish variations for location purposes. 142 Registration, control, and documentation of a higher level service 143 token's extensions is not the concern of IANA unless an IESG approved 144 RFC creates an IANA registration for that token's extenstions. 146 5. Security Considerations 148 The security considerations as essentially the same as in RFC 2782. 150 Normative References 152 [RFC 1035] - "Domain names - Implementation and Specification", Paul 153 Mockapetris, November 1987. 155 [RFC 2782] - "A DNS RR for specifying the location of services (DNS 156 SRV)", A. Gulbrandsen, P. Vixie, L. Esibov, February 2000. 158 Informative References 160 [RFC 2801] - "Internet Open Trading Protocol - IOTP Version 1.0", D. 161 Burdett, April 2000. 163 [XML XKMS] - "XML Key Management Specification (XKMS 2.0)", Phillip 164 Hallam-Baker, August 2002, 165 167 Authors Address 169 Donald E. Eastlake 3rd 170 Motorola 171 155 Beaver Street 172 Milford, MA 01757 USA 174 Phone: +1-508-851-8280 (w) 175 +1-508-634-2066 (h) 176 Email: Donald.Eastlake@motorola.com 178 Full Copyright Statement 180 Copyright (c) 2002 The Internet Society, All Rights Reserved. 182 This document and translations of it may be copied and furnished to 183 others, and derivative works that comment on or otherwise explain it 184 or assist in its implementation may be prepared, copied, published 185 and distributed, in whole or in part, without restriction of any 186 kind, provided that the above copyright notice and this paragraph are 187 included on all such copies and derivative works. However, this 188 document itself may not be modified in any way, such as by removing 189 the copyright notice or references to the Internet Society or other 190 Internet organizations, except as needed for the purpose of 191 developing Internet standards in which case the procedures for 192 copyrights defined in the Internet Standards process must be 193 followed, or as required to translate it into languages other than 194 English. 196 The limited permissions granted above are perpetual and will not be 197 revoked by the Internet Society or its successors or assigns. 199 This document and the information contained herein is provided on an 200 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 201 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 202 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 203 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 204 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 206 File name and Expiration 208 This file is draft-ietf-trade-srv-higher-services-00.txt. 210 It expires April 2003.