Network Working Group J. YAO Internet-Draft X. Lee Intended status: Informational CNNIC Expires: March 15, 2010 September 11, 2009 Chinese Common Name to Uniform Resource Identifier(URI) Dynamic Delegation Discovery System(DDDS) Application(CCN) draft-yao-ccn-ddds-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 15, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document discusses the use of the Domain Name System(DNS) for storage of Chinese Common Name to URI mapping. More specifically, YAO & Lee Expires March 15, 2010 [Page 1] Internet-Draft CCN2U Mapping DDDS Application September 2009 how DNS can be used for identifying URIs or services associated with the Chinese Common Names. The method used to discover the mapping is the Dynamic Delegation Discovery System, which can be found in a series of documents specified in RFC 3401. Understanding of RFC 3401 is necessary for understanding this document. Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. CCN Framework Overview . . . . . . . . . . . . . . . . . . . . 3 4. Preprocessing . . . . . . . . . . . . . . . . . . . . . . . . 4 5. CCN Resolver . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. The CCN2U Application Specification . . . . . . . . . . . . . 5 6.1. Application Unique String . . . . . . . . . . . . . . . . 5 6.2. First Well Known Rule . . . . . . . . . . . . . . . . . . 5 6.3. Expected Output . . . . . . . . . . . . . . . . . . . . . 5 6.4. Valid Database . . . . . . . . . . . . . . . . . . . . . . 5 6.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 6.4.2. Service parameters . . . . . . . . . . . . . . . . . . 7 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. CCNservice . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. CCNservice Registration and Publishing Mechanism . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 13.1. Normative References . . . . . . . . . . . . . . . . . . . 9 13.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 YAO & Lee Expires March 15, 2010 [Page 2] Internet-Draft CCN2U Mapping DDDS Application September 2009 1. Problem Statement ENUM [RFC 3761] provides the E.164 number mapping and how DNS can be used for identifying available services connected to one E.164 number. This document specifies the use of the Domain Name System(DNS) for storage of Chinese Common Name to URI mapping. More specifically, how DNS can be used for identifying URIs or services associated with the Chinese Common Names. Many people are more familiar with the object's Chinese Common Name, such as "Peking university" than its domain name "pku.edu.cn". Some service providers also provide some services such as vCard to ordinary Internet users through Chinese Common Name. In this situation, the ability to directly access the service or URI by the Chinese Common Name will greatly ease users' navigating experience. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. All other capitalized termed are taken from the vocabulary found in the DDDS algorithm specification[RFC3403]. 3. CCN Framework Overview The DDDS framework is used to achieve the mapping and resolution. The CCN registry is required to create a CCN domain for the storage of mapping information. Each registered Chinese Common Name (CCN) will be translated into a domain name and will have a mapping entry in the CCN domain. The rule stored in the CCN domainis responsible for translating each application unique string (AUS) to a domain name. Prior to the DDDS algorithm, the preprocessing procedure regulates the user's input. The output of the preprocessing is the AUS which will serve as the input of the DDDS algorithm. The DDDS algorithm takes the AUS as an input and complete the resolution process to obtain the mapping information. YAO & Lee Expires March 15, 2010 [Page 3] Internet-Draft CCN2U Mapping DDDS Application September 2009 4. Preprocessing The preprocessing is to obtain the user's input(possibly with its context) and construct the AUS. The AUS's syntax is defined as follows: AUS = country-code delim name delim = ":" where country-code is any valid country code specified in ISO 3166 [ISO3166-1]. The country code for China is "CN". Other country-code other than "CN" will be reserved. The name is a valid Chinese Common Name. This Chinese Common Name can have more than one word, separated by blank characters. The requirement for every word allowed in the CCN is same as the requirement for the IDN label [RFC3490]. To form the AUS, the preprocessing should: 1: obtain the country-code either from user's explicit input, or from user's implicit context such as CCN resolver described in section 5 of this document; 2: obtain the input of Chinese Common Name, and replace the blank characters with "-" if there is one. The result serves as the name part of the AUS definition. 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 preprocessing procedure follows the steps below: o if the first part of the input name contains ohter country-codes other than "CN", then the CCN resolver SHOULD regard this input name as invalid and return the error information to the user. o If the first part of the input name contain the country-code "CN", it means the user explicitly input the country-code, and the latter part is treated as the Chinese Common Name. o if the first part of the input name doesn't contain "CN", then the country-code should be obtained from the CCN resolver which includes the default "CN" country-code. If the Chinese Common Name part of the input name has more than one word, replace all blank characters with "-". The AUS is formed by concatenating the country-code, the colon ":", and the Chinese Common Name (after blank character replacement). YAO & Lee Expires March 15, 2010 [Page 4] Internet-Draft CCN2U Mapping DDDS Application September 2009 5. CCN Resolver CCN resolvers act as the CCN resolver of CCN system, which get the input from the users, finish the preprocessing, form the AUS, search the DDDS database, resolve the AUS and return the information to the user. 6. The CCN2U Application Specification This template defines the Chinese Common Name to URI mapping DDDS application according to the rules and requirements found in DDDS, which is specified in RFC 3401 [RFC3403] and RFC 3402 [RFC3403]. The DDDS database used by this application is defined in RFC 3403 [RFC3403], which is also the official document that defines the NAPTR DNS Resource Record type. 6.1. Application Unique String The application unique string is the output of the preprocessing. The format is also defined as mentioned above. 6.2. First Well Known Rule The first well known rule for this application is to extract the country-code part of the AUS, i.e., the output of the first well known rule is the country-code of the AUS. 6.3. Expected Output The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the "absoluteURI" production in the Collected ABNF found in RFC 3986 [RFC3986]. 6.4. Valid Database At present only one DDDS Database is specified for this application. "Dynamic Delegation Discovery System(DDDS) Part Three: The DNS Database"RFC 3403 [RFC3403] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The keys for this database are encoded as domain-names. Note that the keys are valid IDNs as specified in RFC 3490 [RFC3490]. How the IDNs are encoded and stored in the database is out of the scope of this memo. Currently, the IDNA specifies that each IDN label is encoded as an ACE(ASCII Compatible Encoding) label. A simple and efficient transfer encoding syntax designed for use with IDNA is the Puyncode specified in RFC 3492 [RFC3492]. YAO & Lee Expires March 15, 2010 [Page 5] Internet-Draft CCN2U Mapping DDDS Application September 2009 The output of the First Well Known Rule for the mapping Application is the country-code part of AUS. The country-code itself can be used as the first valid key to search the DNS database, requesting NAPTR records from the DNS. The character set used to encode the substitution expression is UTF-8. The allowed input characters are all those characters that are allowed anywhere in a valid common name. The characters allowed to be in a Key of the database are those that are currently defined for DNS domain-names. 6.4.1. Flags This database contains a field to encode flags that signal when the DDDS algorithm has finished. At this time only one flag, "U", is defined, conforming to RFC 3404 [RFC3404]. This flag means that this Rule is the last one and that the output of the rule is a URI. If a CCN resolver encounters a record with an unknown flag, it MUST ignore it and move to the next Rule. This test takes precedence over any ordering since flags can control the interpretation placed on fields. If this flag is not present then this rule is non-terminal. If a Rule is non-terminal then CCN resolvers MUST use the Key produced by this Rewrite Rule as the new key in the DDDS loop(i.e, causing the CCN resolver to query for new NAPTR records at the domain-name that is the result of this Rule) YAO & Lee Expires March 15, 2010 [Page 6] Internet-Draft CCN2U Mapping DDDS Application September 2009 6.4.2. Service parameters Service Parameters for this Application take the following form and are found in the Service field of the NAPTR record. service-field = "CCN2U" [servicespec] servicespec = "+" CCNservice CCNservice = 1*32(alpha / digit) alpha = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" In other words, the service parameter is a non-optional "CCN2U"(used to denote CCN only Rewrite Rules in order to mitigate record collision) followed by an optional servicespec which indicates the servicespec of the final URI. The servicespec can be used by the CCN resolver to determine whether the rule meets the CCN resolver's requirements, as described in step 4 of the comprehensive DDDS algorithm defined in RFC 3402 [RFC3402]. For non-terminal rules, the servicespec field is of no use and SHOULD be ignored. If the servicespec field is absent, the CCN resolver application SHOULD use the default servicespec field "http". 7. Examples The examples below show how the rewrite rules look like and how the resolutions take place, illustrating the usage in typical scenarios. These examples are for pedagogical purposes only. Assume "example" and "example1 example2" are two Chinese Common Names registered in China, whose country-code is CN, and suppose "kw.cn" is reserved for storage of CCNs registered in China. The rewrite rules for "cn" will contain a single NAPTR record: $ORIGIN cn @ IN NAPTR 100 10 "" "CCN2U" "!^cn:(.*)$!\1.kw.cn!i" . YAO & Lee Expires March 15, 2010 [Page 7] Internet-Draft CCN2U Mapping DDDS Application September 2009 The corresponding domain names for the two common names are "example.kw.cn" and "example1-example2.kw.cn" respectively, and the rewrite rules stored in "kw.cn" look like: example IN NAPTR 100 10 "U" "CCN2U+ftp" "!^.*$!ftp.example.com!i" . IN NAPTR 100 20 "U" "CCN2U+http" "!^.*$!www.example.com!i" . example1-example2 IN NAPTR 100 10 "U" "CCN2U" "!^.*$!www.example1-example2.com!i" . 8. CCNservice CCNservice identifys a service associated with the CCN. CCNservice specifications contain the functional specification, the valid protocols, and the URI schemes that may be returned. 9. CCNservice Registration and Publishing Mechanism CCNservice is made up of 'types'. A complete registration of types should include the allowed URI schemes, a functional specification, security considerations, intended usage, and any other information needed to allow for interoperability within CCNservice. All registered CCNservice should be available to all CCNservice implementers and users from the CCN registry who provides the registraion of CCN to internet users. 10. Security Considerations CCN system is based on the DNS, so the threats to CCN system is similar to the threats to DNS. A deployed CCN2U mapping system SHOULD be aware of all these threats to DNS. 11. IANA Considerations There is no special requirement for the IANA to make this application deployable. 12. Acknowledgments We have discussed Chinese Common Name issue with many experts, including (but not limited to) John C Klensin, Harald Tveit Alvestrand, Paul Hoffman and many JET members. Thanks a lot for YAO & Lee Expires March 15, 2010 [Page 8] Internet-Draft CCN2U Mapping DDDS Application September 2009 their kind suggestions, comments. This issue is also discussed in the IETF application area mailling list. Many members of the mailling list give the kind comments. Guoqiang Zhang has contribution to the initial work of this document. 13. References 13.1. Normative References [ISO3166-1] International Organization for Standardization, "ISO 3166- 1:1997. Codes for the representation of names of contries and their subdivisions -- Part 1: country-codes", 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002. [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. YAO & Lee Expires March 15, 2010 [Page 9] Internet-Draft CCN2U Mapping DDDS Application September 2009 13.2. Informative References [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. Authors' Addresses Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing, CN Phone: +86 10 58813007 Email: yaojk@cnnic.cn Xiaodong Lee CNNIC No.4 South 4th Street, Zhongguancun Beijing, CN Phone: +86 10 58813020 Email: lee@cnnic.cn YAO & Lee Expires March 15, 2010 [Page 10]