idnits 2.17.00 (12 Aug 2021) /tmp/idnits27784/draft-ietf-trade-srv-higher-services-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: ---------------------------------------------------------------------------- ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 95: '...cifier, "Higher" MAY also consist of a...' 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 2003) is 6786 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) == Missing Reference: '2935bis' is mentioned on line 125, but not defined == Unused Reference: 'RFC 1035' is defined on line 152, but no explicit reference was found in the text == Unused Reference: 'RFC 2782' is defined on line 155, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Donald E. Eastlake 3rd 3 Motorola Laboratories 4 Expires April 2004 October 2003 6 DNS SRV Location of Higher Level Services 7 9 Status of this Memo 11 Distribution of this document is unlimited. Comments should be sent 12 to the author or the TRADE working group . 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." The list 25 of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 27 Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) 2003, The Internet Society. All Rights Reserved. 34 Abstract 36 The DNS naming conventions specified in RFC 2782 are extended to 37 higher level services and a registry created for the tokens used. 39 Table of Contents 41 Status of this Memo........................................1 42 Copyright Notice...........................................1 43 Abstract...................................................1 44 Table of Contents..........................................2 46 1. Introduction............................................3 47 2. Specification...........................................3 48 3. International Considerations............................4 49 4. IANA Considerations.....................................4 50 5. Security Considerations.................................4 52 Normative References.......................................5 53 Informative References.....................................5 55 Authors Addresses..........................................6 57 Full Copyright Statement...................................7 58 File name and Expiration...................................7 60 1. Introduction 62 RFC 2782 specifies a DNS SRV Resource Record for the location of 63 services. In addition, it provides a DNS naming convention for the 64 DNS nodes at which such SRV RRs are stored. That is the form 65 _Service._Proto.name.example 66 as the name of the DNS node at which SRV RRs would be stored for 67 obtaining the "Service" from "name.example". 69 While there are a variety of means for locating higher level 70 application services, some such services may wish to use the SRV RR. 71 Such higher level services would, typically, be provided over the 72 sorts of services that the RFC 2782 syntax is designed to specify. 73 This document extends that syntax so that higher level protocols can 74 be specified. 76 2. Specification 78 SRV RRs can be stored at nodes with names of the following form 79 _Higher._Service._Proto.name.example 80 For example 81 _iotp._http._tcp.example.net. 83 The definition of the "_Proto" DNS label is the same as in RFC 2782. 85 For the use described in this document, the "_Service" DNS label is a 86 port specifying token registered with IANA in Assigned Numbers (such 87 as http or ldap), prefixed with an underscore character. 89 The DNS label "_Higher" is a token consisting from 1 to 12 ASCII 90 letters and digits, registered as provided in Section 4 below, and 91 prefixed with an underscore character. 93 Higher level protocols sometimes have a number of services. To 94 minimize the burden on the registration authority and maximize 95 convenience to the protocol specifier, "Higher" MAY also consist of a 96 token (as registered hereunder) followed by a hyphen character, 97 followed by any characters allowed in connection with location of the 98 higher level service. For example 99 _xkms-xkiss-soap._http._tcp.example.org. 101 Neither this specification nor registration hereunder implies over 102 what services or protocols a higher level service can be used. Such 103 limitations are specified in connection with that higher level 104 service. For example, you need to look at the IOTP related 105 specification for any information as to whether 106 _iotp._smtp._sctp.foo.example 107 could be useful. 109 Due to the case insensitive nature of DNS labels [RFC 1035, case], 110 all of "_Higher", "_Service", and "_Proto" are case insensitive. 112 3. International Considerations 114 The fully qualified DNS names discussed in this document and the 115 Higher, Service, and Proto tokens appearing therein will normally be 116 program generated and not seen by users. Thus no internationalization 117 provisions are made. 119 4. IANA Considerations 121 IANA will maintain a registry of higher level application designating 122 tokens for use as specified in Section 2 above. The initial contents 123 of the registry will be the two tokens 125 IOTP - [RFC 2801, 2935bis] 126 XKMS - [XML XKMS] 128 Registration of additional tokens is based on the documentation of 129 each token in an RFC or a similar free publicly accessible and 130 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 extent 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 [RFC case] - "Domain Name System (DNS) Case Insensitivity 159 Clarification", draft-ietf-dnsext-insensitive 161 Informative References 163 [RFC 2801] - "Internet Open Trading Protocol - IOTP Version 1.0", D. 164 Burdett, April 2000. 166 [RFC 2935bis] - draft-ietf-trade-iotp-http2, "Internet Open Trading 167 Protocol (IOTP) HTTP Supplement". 169 [XML XKMS] - "XML Key Management Specification (XKMS 2.0)", Phillip 170 Hallam-Baker, August 2002, 171 173 Authors Addresses 175 Donald E. Eastlake 3rd 176 Motorola Laboratories 177 155 Beaver Street 178 Milford, MA 01757 USA 180 Phone: +1-508-786-7554 (w) 181 +1-508-634-2066 (h) 182 Email: Donald.Eastlake@motorola.com 184 Full Copyright Statement 186 Copyright (c) 2003 The Internet Society, All Rights Reserved. 188 This document and translations of it may be copied and furnished to 189 others, and derivative works that comment on or otherwise explain it 190 or assist in its implementation may be prepared, copied, published 191 and distributed, in whole or in part, without restriction of any 192 kind, provided that the above copyright notice and this paragraph are 193 included on all such copies and derivative works. However, this 194 document itself may not be modified in any way, such as by removing 195 the copyright notice or references to the Internet Society or other 196 Internet organizations, except as needed for the purpose of 197 developing Internet standards in which case the procedures for 198 copyrights defined in the Internet Standards process must be 199 followed, or as required to translate it into languages other than 200 English. 202 The limited permissions granted above are perpetual and will not be 203 revoked by the Internet Society or its successors or assigns. 205 This document and the information contained herein is provided on an 206 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 207 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 208 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 209 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 210 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 212 File name and Expiration 214 This file is draft-ietf-trade-srv-higher-services-01.txt. 216 It expires April 2004.