idnits 2.17.1 draft-yao-ccn-ddds-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In order to identify whether users explicitly input country-code or not, "CN" and other country-codes MUST not be the first word of any registered common names. This should be the registration policy of the CCN registry. -- The document date (September 11, 2009) is 5341 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 3761' is mentioned on line 82, but not defined ** Obsolete undefined reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) == Unused Reference: 'RFC2535' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC4234' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'RFC3401' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC3833' is defined on line 380, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. YAO 3 Internet-Draft X. Lee 4 Intended status: Informational CNNIC 5 Expires: March 15, 2010 September 11, 2009 7 Chinese Common Name to Uniform Resource Identifier(URI) Dynamic 8 Delegation Discovery System(DDDS) Application(CCN) 9 draft-yao-ccn-ddds-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 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." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 15, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document discusses the use of the Domain Name System(DNS) for 48 storage of Chinese Common Name to URI mapping. More specifically, 49 how DNS can be used for identifying URIs or services associated with 50 the Chinese Common Names. The method used to discover the mapping is 51 the Dynamic Delegation Discovery System, which can be found in a 52 series of documents specified in RFC 3401. Understanding of RFC 3401 53 is necessary for understanding this document. 55 Table of Contents 57 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 3. CCN Framework Overview . . . . . . . . . . . . . . . . . . . . 3 60 4. Preprocessing . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. CCN Resolver . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. The CCN2U Application Specification . . . . . . . . . . . . . 5 63 6.1. Application Unique String . . . . . . . . . . . . . . . . 5 64 6.2. First Well Known Rule . . . . . . . . . . . . . . . . . . 5 65 6.3. Expected Output . . . . . . . . . . . . . . . . . . . . . 5 66 6.4. Valid Database . . . . . . . . . . . . . . . . . . . . . . 5 67 6.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.4.2. Service parameters . . . . . . . . . . . . . . . . . . 7 69 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8. CCNservice . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 9. CCNservice Registration and Publishing Mechanism . . . . . . . 8 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 9 77 13.2. Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Problem Statement 82 ENUM [RFC 3761] provides the E.164 number mapping and how DNS can be 83 used for identifying available services connected to one E.164 84 number. This document specifies the use of the Domain Name 85 System(DNS) for storage of Chinese Common Name to URI mapping. More 86 specifically, how DNS can be used for identifying URIs or services 87 associated with the Chinese Common Names. Many people are more 88 familiar with the object's Chinese Common Name, such as "Peking 89 university" than its domain name "pku.edu.cn". Some service 90 providers also provide some services such as vCard to ordinary 91 Internet users through Chinese Common Name. In this situation, the 92 ability to directly access the service or URI by the Chinese Common 93 Name will greatly ease users' navigating experience. 95 2. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in BCP 14, RFC 2119 100 [RFC2119]. 102 All other capitalized termed are taken from the vocabulary found in 103 the DDDS algorithm specification[RFC3403]. 105 3. CCN Framework Overview 107 The DDDS framework is used to achieve the mapping and resolution. 108 The CCN registry is required to create a CCN domain for the storage 109 of mapping information. Each registered Chinese Common Name (CCN) 110 will be translated into a domain name and will have a mapping entry 111 in the CCN domain. The rule stored in the CCN domainis responsible 112 for translating each application unique string (AUS) to a domain 113 name. Prior to the DDDS algorithm, the preprocessing procedure 114 regulates the user's input. The output of the preprocessing is the 115 AUS which will serve as the input of the DDDS algorithm. The DDDS 116 algorithm takes the AUS as an input and complete the resolution 117 process to obtain the mapping information. 119 4. Preprocessing 121 The preprocessing is to obtain the user's input(possibly with its 122 context) and construct the AUS. The AUS's syntax is defined as 123 follows: 125 AUS = country-code delim name 126 delim = ":" 128 where country-code is any valid country code specified in ISO 3166 129 [ISO3166-1]. The country code for China is "CN". Other country-code 130 other than "CN" will be reserved. The name is a valid Chinese Common 131 Name. This Chinese Common Name can have more than one word, 132 separated by blank characters. The requirement for every word 133 allowed in the CCN is same as the requirement for the IDN label 134 [RFC3490]. 136 To form the AUS, the preprocessing should: 137 1: obtain the country-code either from user's explicit input, or 138 from user's implicit context such as CCN resolver described in 139 section 5 of this document; 140 2: obtain the input of Chinese Common Name, and replace the blank 141 characters with "-" if there is one. The result serves as the 142 name part of the AUS definition. 144 In order to identify whether users explicitly input country-code or 145 not, "CN" and other country-codes MUST not be the first word of any 146 registered common names. This should be the registration policy of 147 the CCN registry. 149 The preprocessing procedure follows the steps below: 150 o if the first part of the input name contains ohter country-codes 151 other than "CN", then the CCN resolver SHOULD regard this input 152 name as invalid and return the error information to the user. 153 o If the first part of the input name contain the country-code "CN", 154 it means the user explicitly input the country-code, and the 155 latter part is treated as the Chinese Common Name. 156 o if the first part of the input name doesn't contain "CN", then the 157 country-code should be obtained from the CCN resolver which 158 includes the default "CN" country-code. 159 If the Chinese Common Name part of the input name has more than one 160 word, replace all blank characters with "-". 162 The AUS is formed by concatenating the country-code, the colon ":", 163 and the Chinese Common Name (after blank character replacement). 165 5. CCN Resolver 167 CCN resolvers act as the CCN resolver of CCN system, which get the 168 input from the users, finish the preprocessing, form the AUS, search 169 the DDDS database, resolve the AUS and return the information to the 170 user. 172 6. The CCN2U Application Specification 174 This template defines the Chinese Common Name to URI mapping DDDS 175 application according to the rules and requirements found in DDDS, 176 which is specified in RFC 3401 [RFC3403] and RFC 3402 [RFC3403]. The 177 DDDS database used by this application is defined in RFC 3403 178 [RFC3403], which is also the official document that defines the NAPTR 179 DNS Resource Record type. 181 6.1. Application Unique String 183 The application unique string is the output of the preprocessing. 184 The format is also defined as mentioned above. 186 6.2. First Well Known Rule 188 The first well known rule for this application is to extract the 189 country-code part of the AUS, i.e., the output of the first well 190 known rule is the country-code of the AUS. 192 6.3. Expected Output 194 The output of the last DDDS loop is a Uniform Resource Identifier in 195 its absolute form according to the "absoluteURI" production in the 196 Collected ABNF found in RFC 3986 [RFC3986]. 198 6.4. Valid Database 200 At present only one DDDS Database is specified for this application. 201 "Dynamic Delegation Discovery System(DDDS) Part Three: The DNS 202 Database"RFC 3403 [RFC3403] specifies a DDDS Database that uses the 203 NAPTR DNS resource record to contain the rewrite rules. The keys for 204 this database are encoded as domain-names. Note that the keys are 205 valid IDNs as specified in RFC 3490 [RFC3490]. How the IDNs are 206 encoded and stored in the database is out of the scope of this memo. 207 Currently, the IDNA specifies that each IDN label is encoded as an 208 ACE(ASCII Compatible Encoding) label. A simple and efficient 209 transfer encoding syntax designed for use with IDNA is the Puyncode 210 specified in RFC 3492 [RFC3492]. 212 The output of the First Well Known Rule for the mapping Application 213 is the country-code part of AUS. The country-code itself can be used 214 as the first valid key to search the DNS database, requesting NAPTR 215 records from the DNS. 217 The character set used to encode the substitution expression is 218 UTF-8. The allowed input characters are all those characters that 219 are allowed anywhere in a valid common name. The characters allowed 220 to be in a Key of the database are those that are currently defined 221 for DNS domain-names. 223 6.4.1. Flags 225 This database contains a field to encode flags that signal when the 226 DDDS algorithm has finished. At this time only one flag, "U", is 227 defined, conforming to RFC 3404 [RFC3404]. This flag means that this 228 Rule is the last one and that the output of the rule is a URI. 230 If a CCN resolver encounters a record with an unknown flag, it MUST 231 ignore it and move to the next Rule. This test takes precedence over 232 any ordering since flags can control the interpretation placed on 233 fields. 235 If this flag is not present then this rule is non-terminal. If a 236 Rule is non-terminal then CCN resolvers MUST use the Key produced by 237 this Rewrite Rule as the new key in the DDDS loop(i.e, causing the 238 CCN resolver to query for new NAPTR records at the domain-name that 239 is the result of this Rule) 241 6.4.2. Service parameters 243 Service Parameters for this Application take the following form and 244 are found in the Service field of the NAPTR record. 246 service-field = "CCN2U" [servicespec] 247 servicespec = "+" CCNservice 248 CCNservice = 1*32(alpha / digit) 249 alpha = "a" / "b" / "c" / "d" / "e" / "f" / "g" / 250 "h" / "i" / "j" / "k" / "l" / "m" / "n" / 251 "o" / "p" / "q" / "r" / "s" / "t" / "u" / 252 "v" / "w" / "x" / "y" / "z" / 253 "A" / "B" / "C" / "D" / "E" / "F" / "G" / 254 "H" / "I" / "J" / "K" / "L" / "M" / "N" / 255 "O" / "P" / "Q" / "R" / "S" / "T" / "U" / 256 "V" / "W" / "X" / "Y" / "Z" 257 digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / 258 "7" / "8" / "9" 260 In other words, the service parameter is a non-optional "CCN2U"(used 261 to denote CCN only Rewrite Rules in order to mitigate record 262 collision) followed by an optional servicespec which indicates the 263 servicespec of the final URI. The servicespec can be used by the CCN 264 resolver to determine whether the rule meets the CCN resolver's 265 requirements, as described in step 4 of the comprehensive DDDS 266 algorithm defined in RFC 3402 [RFC3402]. 268 For non-terminal rules, the servicespec field is of no use and SHOULD 269 be ignored. If the servicespec field is absent, the CCN resolver 270 application SHOULD use the default servicespec field "http". 272 7. Examples 274 The examples below show how the rewrite rules look like and how the 275 resolutions take place, illustrating the usage in typical scenarios. 276 These examples are for pedagogical purposes only. 278 Assume "example" and "example1 example2" are two Chinese Common Names 279 registered in China, whose country-code is CN, and suppose "kw.cn" is 280 reserved for storage of CCNs registered in China. The rewrite rules 281 for "cn" will contain a single NAPTR record: 283 $ORIGIN cn 284 @ IN NAPTR 100 10 "" "CCN2U" "!^cn:(.*)$!\1.kw.cn!i" . 286 The corresponding domain names for the two common names are 287 "example.kw.cn" and "example1-example2.kw.cn" respectively, and the 288 rewrite rules stored in "kw.cn" look like: 290 example 291 IN NAPTR 100 10 "U" "CCN2U+ftp" "!^.*$!ftp.example.com!i" . 292 IN NAPTR 100 20 "U" "CCN2U+http" "!^.*$!www.example.com!i" . 294 example1-example2 295 IN NAPTR 100 10 "U" "CCN2U" "!^.*$!www.example1-example2.com!i" . 297 8. CCNservice 299 CCNservice identifys a service associated with the CCN. CCNservice 300 specifications contain the functional specification, the valid 301 protocols, and the URI schemes that may be returned. 303 9. CCNservice Registration and Publishing Mechanism 305 CCNservice is made up of 'types'. A complete registration of types 306 should include the allowed URI schemes, a functional specification, 307 security considerations, intended usage, and any other information 308 needed to allow for interoperability within CCNservice. All 309 registered CCNservice should be available to all CCNservice 310 implementers and users from the CCN registry who provides the 311 registraion of CCN to internet users. 313 10. Security Considerations 315 CCN system is based on the DNS, so the threats to CCN system is 316 similar to the threats to DNS. A deployed CCN2U mapping system 317 SHOULD be aware of all these threats to DNS. 319 11. IANA Considerations 321 There is no special requirement for the IANA to make this application 322 deployable. 324 12. Acknowledgments 326 We have discussed Chinese Common Name issue with many experts, 327 including (but not limited to) John C Klensin, Harald Tveit 328 Alvestrand, Paul Hoffman and many JET members. Thanks a lot for 329 their kind suggestions, comments. This issue is also discussed in 330 the IETF application area mailling list. Many members of the 331 mailling list give the kind comments. Guoqiang Zhang has 332 contribution to the initial work of this document. 334 13. References 336 13.1. Normative References 338 [ISO3166-1] 339 International Organization for Standardization, "ISO 3166- 340 1:1997. Codes for the representation of names of contries 341 and their subdivisions -- Part 1: country-codes", 1997. 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, March 1997. 346 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 347 RFC 2535, March 1999. 349 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 350 Part Two: The Algorithm", RFC 3402, October 2002. 352 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 353 Part Three: The Domain Name System (DNS) Database", 354 RFC 3403, October 2002. 356 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 357 Part Four: The Uniform Resource Identifiers (URI)", 358 RFC 3404, October 2002. 360 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 361 "Internationalizing Domain Names in Applications (IDNA)", 362 RFC 3490, March 2003. 364 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 365 for Internationalized Domain Names in Applications 366 (IDNA)", RFC 3492, March 2003. 368 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 369 Resource Identifier (URI): Generic Syntax", STD 66, 370 RFC 3986, January 2005. 372 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 373 Specifications: ABNF", RFC 4234, October 2005. 375 13.2. Informative References 377 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 378 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 380 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 381 Name System (DNS)", RFC 3833, August 2004. 383 Authors' Addresses 385 Jiankang YAO 386 CNNIC 387 No.4 South 4th Street, Zhongguancun 388 Beijing, 389 CN 391 Phone: +86 10 58813007 392 Email: yaojk@cnnic.cn 394 Xiaodong Lee 395 CNNIC 396 No.4 South 4th Street, Zhongguancun 397 Beijing, 398 CN 400 Phone: +86 10 58813020 401 Email: lee@cnnic.cn