Internet DRAFT - draft-yao-ccn-ddds
draft-yao-ccn-ddds
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]
