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]