Universally Traceable Identifier (UTID)
draft-huangng-utid-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | huangng@gmail.com | ||
| Last updated | 2013-12-02 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-huangng-utid-01
Independent Submission N. G. Huang
Internet Draft Wuxi Institute of Technology
Intended status: Experimental December 2, 2013
Expires: June 2014
Universally Traceable Identifier (UTID)
draft-huangng-utid-01.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 June 2, 2014.
N. G. Huang Expires June 2, 2014 [Page 1]
Internet-Draft UTID December 2013
Copyright Notice
Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
A Universally Traceable Identifier (UTID) is a compact string of
characters for identifying an abstract or physical object. A unique
feature of UTID is that it contains two types of forwarding messages
to achieve traceability. UTIDs are designed specially for Identifier
Tracing Protocol (ITDP) [I-D-IDTP].
This document defines the generic syntax of UTID, a generative
grammar for UTID, and the guidelines for their use, too.
Table of Contents
1. Introduction................................................3
1.1. Overview of UTIDs......................................3
1.2. Terminology............................................4
1.3. UTIDs and URIs.........................................5
2. Conventions Used in This Document............................5
3. Characters..................................................5
3.1. Reserved Characters.....................................6
3.2. Unreserved Characters...................................6
4. Syntax Components...........................................6
4.1. Dns....................................................6
4.2. Location...............................................6
4.3. Catalog................................................7
4.4. Id.....................................................7
5. Formal Syntax...............................................7
5.1. UTID Syntax............................................7
5.1.1. Maximum Length of UTIDs............................8
5.1.2. Dns...............................................8
5.1.3. Id................................................8
5.1.4. Nested UTID.......................................9
5.2. Examples...............................................9
N. G. Huang Expires June 2, 2014 [Page 2]
Internet-Draft UTID December 2013
6. Usage......................................................10
6.1. Components Omitted....................................10
6.1.1. Location Omitted..................................10
6.1.2. Catalog Omitted...................................10
6.1.3. Id Omitted.......................................11
6.1.4. Dns Only.........................................11
6.2. Without Dns...........................................11
6.3. Spaces................................................11
6.4. Carrier of UTIDs......................................12
7. Normalization and Comparison................................12
7.1. Normalization.........................................12
7.2. Equivalence...........................................14
7.3. UTID Suffix Match Algorithm............................14
8. Security Considerations....................................15
9. IANA Considerations........................................15
10. References................................................15
10.1. Normative References..................................15
10.2. Informative References................................16
11. Acknowledgments...........................................17
Appendix A. Parsing a UTID with a Regular Expression...........18
Appendix B. Delimiting a UTID in Context.......................20
1. Introduction
A Universal Traceable Identifier (UTID) provides a simple and
extensible means for identifying an abstract object and a physical
object. This specification of UTID syntax and semantic is derived
from concepts introduced by the Identifier Tracing Protocol (IDTP)
[I-D-IDTP], which is a new communication protocol designed for
tracing an object and is initially presented in a reference
[Huang2011]. The syntax and semantic of UTID is designed to meet the
requirements needed for the operating of IDTP.
A reference implementation, which is called "busilet", of UTID and
IDTP has been developed as open source software and could be
downloaded from http://sourceforge.net/projects/busilet/. For more
information please visit http://www.utid.org.
1.1. Overview of UTIDs
UTIDs are characterized as follows:
N. G. Huang Expires June 2, 2014 [Page 3]
Internet-Draft UTID December 2013
o Universality: Universality provides several benefits. It allows
UTIDs to be used for different types of objects in various
contexts with same syntax. It allows UTIDs to be compatible with
preexisting identifiers defined in various existing
identification system.
o Traceability: UTIDs contain forwarding messages used by IDTP [I-
D-IDTP] to trace the origin of the information associated to the
objects identified by the UTIDs. There two types of forwarding
messages contained in UTID used by IDTP. This is a unique feature
of UTIDs and IDTP comparing to URIs and other communication
protocol. This is why a new identification system and
communication protocol are proposed.
o Identifier: An identifier embodies the information required to
distinguish what is being identified from all other objects
within its scope of identification.
A UTID is an identifier consisting of a sequence of characters
matching the syntax rule named <UTID> in Section 5.1. This
specification does not place any limits on the nature of an object.
UTIDs have a global scope and are interpreted consistently
regardless of context.
1.2. Terminology
This specification uses a number of terms related to UTID for
understanding the concept of UTID.
o Traceability: It refers to the ability to trace the history,
application or location of an entity by means of recorded
identifications [ISO8402]. The concept of entity in this document
is extended to abstract objects and physical objects.
o Object: It is refer to an abstract object or a physical object in
this document.
o IDTP: It is Identifier Tracing Protocol, as defined in reference
[I-D-IDTP]. UTIDs are designed specially for IDTP.
o FQUTID: It is full qualified UTID, as defined in Section 7.1.
o UTID suffix: It is the last part of a FQUTID starting from a
given position, as defined in Section 7.3.
N. G. Huang Expires June 2, 2014 [Page 4]
Internet-Draft UTID December 2013
o Tracing: It is the process to trace a request to its origin
server by forwarding the request. It is a special kind of
forwarding for the purpose of traceability.
1.3. UTIDs and URIs
A UTID is similar to Uniform Resource Identifier (URI) defined by
RFC3986 [RFC3986]. URIs are uniform identifiers for general purposes.
UTIDs defined in this document are universal identifiers for IDTP
only. Their differences are as follows:
1. Syntax: There are no percent-encoding characters used to
represent predefined delimiters in components in UTIDs.
2. Nested: A UTID can nest another UTID as its component, even with
two or three nested levels.
3. Traceability: A UTID contains two types of forwarding messages to
achieve traceability.
4. Usage: URIs are uniform identifiers for general purposes, while
UTIDs are universal identifiers designed for IDTP only.
UTIDs are not compatible with URIs because of the differences
described above. Therefore, UTIDs could not become a scheme under
URIs scheme architecture.
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 RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
This specification uses the terms "character" in accordance with the
definitions provided in [BCP19].
3. Characters
A UTID is composed from a set of characters consisting of digits,
letters, and graphic symbols. A reserved subset of those characters
may be used to delimit syntax components within a UTID while the
remaining characters, including both the unreserved set and those
N. G. Huang Expires June 2, 2014 [Page 5]
Internet-Draft UTID December 2013
reserved characters not acting as delimiters, define each
component's identifying data.
3.1. Reserved Characters
UTIDs include components that are delimited by characters in the
"reserved" set. These characters are called "reserved" because they
are defined as delimiters by the UTID syntax.
reserved = "~" / "@" / "$"
3.2. Unreserved Characters
Characters that are allowed in a UTID but do not have a reserved
purpose are called unreserved. These include lowercase letters,
decimal digits, hyphen, and period.
unreserved = alpha / DIGIT / "-" / "."
alpha = %x61-7A ; a-z
4. Syntax Components
A UTID consists of four components referred to as the dns, location,
catalog, and id.
4.1. Dns
A dns component is the domain name in Domain Name System (DNS)
defined by RFC1034 and RFC1035 [RFC1034] [RFC1035] for who defines
the UTID and assigns the UTID to an object. It is required and MUST
NOT be empty (no characters).
The dns expresses one type of forwarding message of a UTID, which is
used directly by the TCP/IP network.
4.2. Location
A location component expresses the location message of the object
identified by a UTID in the domain of who defines the UTID. It is
not required and may be empty (no characters).
The location message expresses another type of forwarding message of
a UTID in the domain of who defines the UTID, which is used by IDTP.
N. G. Huang Expires June 2, 2014 [Page 6]
Internet-Draft UTID December 2013
4.3. Catalog
A catalog component expresses the catalog message of the object
identified by a UTID. It is not required and may be empty (no
characters).
The catalog message is used by IDTP to map a UTID to a set of data
format standard for communication, as defined in Section 6.2 of
reference [I-D-IDTP].
4.4. Id
An id component is a string of characters for identifying an object.
It MUST be unique in the context defined by the above three
components. It may be a serial number, a unique string with meaning,
such as user name, or a unique number or string generated by machine.
It is not required but usually is not empty.
5. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-5234 [RFC5234].
5.1. UTID Syntax
The UTID Syntax is as follows:
UTID = [ id ] [ "~" catalog ] [ "@" location ] "$" dns
id = 1 * 92 graphic
catalog = label 0 * 30 dot-label 0 * 1 label
location = label 0 * 30 dot-label 0 * 1 label
dns = label 0 * 60 dot-label "." 2 * 7 alpha
label = alpha / DIGIT
dot-label = alpha / DIGIT / "-" / "."
alpha = %x61-7A ; a-z
graphic = %x21-7E / Graphic Unicode character
N. G. Huang Expires June 2, 2014 [Page 7]
Internet-Draft UTID December 2013
If one component is empty (no characters), the delimiter ('~' or '@')
before the component should be omitted excepting that the id
component contains '~' or '@' in a UTID. On the contrary, no
delimiter may be omitted in FQUTIDs as defined in Section 7.1.
5.1.1. Maximum Length of UTIDs
The maximum length of a UTID is 96 bytes including all delimiters in
the UTID although the sum of the maximum length of each components
is larger than 96. If one component is long, the other components
should be shorter to guarantee that the length of a UTID does not
exceed 96.
5.1.2. Dns
The dns component MUST be a real DNS name registered in a domain
name registration agent and MUST NOT be an IP address or "localhost"
that is a loopback name of local machine. That is to say, there must
be at least one dot '.' in the dns component and the part after the
last dot must be a top-level domain.
The Domain Name System (DNS) [RFC1034] [RFC1035] defines the maximum
length of a DNS is 255. However, to simplify implementations, the
maximum length of a DNS used in UTID is limited to 64, which is
longer than nearly all DNS actually used in real applications.
In the DNS definition, characters used in DNS may be lower case or
upper case without any significance attached to the case. However,
to simplify implementations, the characters used in dns component in
UTID MUST be lower case.
The Internationalizing Domain Names in Applications (IDNA) system
allows user applications, such as web browsers, map Unicode strings
into the valid DNS character set using Punycode, which is called
internationalized domain names. However, to simplify implementations,
internationalized domain names are not allowed in UTIDs.
5.1.3. Id
The id component consists of graphic characters, which include all
graphic characters defined in ISO/IEC 646 [ISO646] except space and
all graphic characters defined in Unicode [Unicode]. The Unicode
character SHOULD be encoded in UTF-8 [STD63] character set.
The id component is case sensitive, while the other three components
support lower case only.
N. G. Huang Expires June 2, 2014 [Page 8]
Internet-Draft UTID December 2013
Space ('%x20') is neither supported by id component nor supported by
the other three components in UTIDs.
The delimiters both of "~" and "@" could not be omitted in a UTID if
the id component of the UTID contains "~" or "@" character.
5.1.4. Nested UTID
A nested UTID is defined as the id component of a UTID is another
UTID. Therefore, the id component of a nested UTID MUST contain dns
component and follow the UTID syntax. On the contrary, a UTID in
which id component contains dns component is not necessary to be a
nested UTID. Whether a UTID is a nested UTID is determined both by
the syntax and the usage context of the UTID.
5.2. Examples
Examples of UTIDs are as follows:
123~cat@loc$abc.example
123@loc$abc.example
123~cat$abc.example
~cat@loc$abc.example
123$abc.example
@loc$abc.example
~cat$abc.example
$abc.example
Examples of nested UTIDs are as follows:
123~cat@loc$abc.example~aaa@bbb$zyx.example
123~cat@loc$abc.example~@$zyx.example
123$abc.example$zyx.example
$abc.example$zyx.example
Examples of non-nested UTIDs in which id contains "$" are as follows:
N. G. Huang Expires June 2, 2014 [Page 9]
Internet-Draft UTID December 2013
123~@$abc~@$zyx.example
123$abc@test~@$zyx.example
6. Usage
A UTID should be used as a whole. There is no concept such as
relative reference in URIs.
One or more components of UTIDs may be omitted, which are discussed
in following.
6.1. Components Omitted
6.1.1. Location Omitted
The location component expresses the forwarding message of a UTID in
the domain of who defines the UTID, which is used by IDTP.
The location component of a UTID is optional. The location component
can be omitted in the following two cases:
o The location message is not concerned in the usage context. For
example, there is no forwarding in the domain of who defines the
UTID.
o The location message is expressed by other components, in which
location message is no longer necessary. For example, the catalog
component in a UTID expresses both catalog message and location
message so that the location component is omitted.
6.1.2. Catalog Omitted
The catalog component is used to map a UTID to a set of data format
standard for communication by IDTP.
If the catalog component is omitted, it means that default catalog
is used. The default catalog of a UTID is an empty string with
length of zero. There is always a catalog in a UTID in spite of
catalog component omitted or not, either explicitly defined by
catalog component in a UTID or implicitly defined by default catalog
of empty string.
N. G. Huang Expires June 2, 2014 [Page 10]
Internet-Draft UTID December 2013
6.1.3. Id Omitted
The id component is scarcely omitted. The id component may be
omitted in the following two cases:
o It does not concern the object that a UTID identifies. Therefore,
the UTID is used only as forwarding messages by IDTP.
o A UTID identifies all objects in the catalog and location
specified in the UTID.
6.1.4. Dns Only
Occasionally, a UTID consists of only dns component without id,
catalog, and location components. In this case, the delimiter '$'
can not be omitted, catalog component is the default catalog of
empty string, and the id and location components are not the
concerns.
The UTID of dns only is used only as forwarding messages by IDTP,
that is, the UTID refers to the origin server referred by dns only.
6.2. Without Dns
A UTID without dns component is invalid. However, UTIDs without dns
component may exist in some special usage context. Such UTIDs are
strictly limited to the interior of server and MUST NOT be
transmitted in communications.
For example, UTIDs are used as primary key in a database, which is a
typical usage of UTIDs. In this case, all the primary key values
have same dns component or even same location and catalog components.
Therefore, the redundant components are not necessary to be saved in
the database and a mechanism of mapping primary key to UTID should
be established in the interior of server.
6.3. Spaces
Space ('%x20') is neither supported in id component nor the other
three components in UTIDs.
It is acceptable for location and catalog components without
supporting of space character. However, it is occasionally happens
that spaces character occur in an id in existing identification
system. In this case, the spaces character should be replaced by
N. G. Huang Expires June 2, 2014 [Page 11]
Internet-Draft UTID December 2013
some other visible characters for compatibility, which is not
defined in this document.
6.4. Carrier of UTIDs
UTIDs may be used in RFID or two dimension bar code as tags to
identify physical objects. UTIDs may also be used in a database as
primary keys or foreign keys to identify physical or abstract
objects. In such cases, the length of UTIDs is critical especially
in RFID and the data structure design of databases. To simplify
implementations, the maximum length of UTIDs is limited to 96 bytes.
If a UTID is used as a primary key in a database, the primary key
values usually are saved without dns component, or even without
location and catalog components and there should be a mechanism to
convert the primary keys to UTIDs in the server interior.
If a UTID is used as a foreign key in a database, the foreign key
values must be saved as whole UTIDs following the syntax of UTIDs.
There is no strict foreign key constraint to the referenced table.
In this case, the foreign key in a table usually refers to many
referenced tables distributed in many databases in local or remote
hosts, which are defined in the forwarding messages (dns and
location components) of UTIDs of foreign key values.
7. Normalization and Comparison
One of the most common operations on UTIDs is comparison to
determine whether two UTIDs are equivalent. In addition, another
most common operation is UTID suffix match performed by IDTP when
matching a UTID to UTID suffixes in tracing rules, as defined in
Section 5.2 in reference [I-D-IDTP].
Normalization prior to comparison of UTIDs or UTID suffix match is
performed by IDTP.
7.1. Normalization
One or more components of UTIDs may be omitted, which results in the
confusion of same UTID with different expression. For example, the
UTIDs below refer to same UTID:
123$abc.example
123@$abc.example
N. G. Huang Expires June 2, 2014 [Page 12]
Internet-Draft UTID December 2013
123~$abc.example
123~@$abc.example
The purpose of normalization is to make a UTID to conform to a
standard form, which is defined as full qualified UTID, or called
FQUTID in short. FQUTID is used to accurately express the components
of a UTID when one or more components are empty (no characters). The
FQUTID is used internally by programmers only when implementing the
UTID and IDTP.
The FQUTID syntax is as follows:
FQUTID = begin [ id ] "~" [ catalog ] "@" [ location ] "$" dns
id = 1 * 92 graphic
catalog = label 0 * 30 dot-label 0 * 1 label
location = label 0 * 30 dot-label 0 * 1 label
dns = label 0 * 60 dot-label "." 2 * 7 alpha
label = alpha / DIGIT
dot-label = alpha / DIGIT / "-" / "."
alpha = %x61-7A ; a-z
graphic = %x21-7E / Graphic Unicode character
begin = %x0B ; '\b'
Where the delimiters of "~" and "@" are not omitted when the catalog
or location component is empty (no characters).
For example, a UTID "123~cat@loc$abc.example" is normalized to
FQUTID of "\b123~cat@loc$abc.example". And the following same UTID
in four forms:
123$abc.example
123@$abc.example
123~$abc.example
N. G. Huang Expires June 2, 2014 [Page 13]
Internet-Draft UTID December 2013
123~@$abc.example
can be normalized to one FQUTID:
\b123~@$abc.example
7.2. Equivalence
The comparison of two UTIDs is performed by comparing their strings
of normalized form FQUTID. The two UTIDs are considered as identical
if the two strings of normalized form of the UTIDs are same.
The comparison of two UTIDs is conducted as follows:
o Both UTIDs should be normalized to FQUTIDs before comparison.
o The comparison success if the two strings of the FQUTIDs are
exactly equal (case sensitive). Otherwise, the comparison is
failure.
7.3. UTID Suffix Match Algorithm
UTID suffix match operation is performed by IDTP to match tracing
rules using the longest UTID suffix match first algorithm.
The UTID suffix match operation is conducted as follows:
o A UTID suffix is defined as the last part of a FQUTID starting
from a given position, which should be before the '$' delimiter
to make sure that the UTID suffix contains the entire dns
component.
o A UTID that is to be matched to a UTID suffix should be
normalized to FQUTID.
o The match success if the FQUTID is ended with the UTID suffix
(case sensitive). Otherwise, the match is failure.
o If one UTID matches more than one UTID suffix, the longest UTID
suffix wins.
Occasionally, a UTID suffix itself is a FQUTID that is used to make
a full match (equivalence match). In such case, both FQUTID and UTID
suffix begins with a beginning mark '\b' and match are performed
using the same UTID suffix match algorithm.
N. G. Huang Expires June 2, 2014 [Page 14]
Internet-Draft UTID December 2013
For example, there are three UTID suffixes sorted by the length of
UTID suffix as follows:
\babc~cat@loc$abc.example
abc~cat@loc$abc.example
bc~cat@loc$abc.example
The FQUTID below matches the second and the third UTID suffix, but
the second UTID suffix wins:
\b123abc~cat@loc$abc.example
The FQUTID below matches all three UTID suffixes, but the first UTID
suffix wins:
\babc~cat@loc$abc.example
8. Security Considerations
This section is meant to inform application developers, information
providers, and users of the security limitations of UTID as
described by this document. The discussion does not include
definitive solutions to the problems revealed, though it does make
some suggestions for reducing security risks.
Although a UTID does not in itself pose a security threat, but a
UTID is in plaintext transmitted over network without encryption.
Hence it exposes to any network sniffer tools and results in the
unintentional leakage of this information during the transferring
over network. There are some potential risks if id, catalog, or
location components contain sensitive information. Therefore, it
should be careful to design the UTID components to avoid leakage of
sensitive information.
9. IANA Considerations
No IANA actions are required by this document.
10. References
10.1. Normative References
[BCP19] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
N. G. Huang Expires June 2, 2014 [Page 15]
Internet-Draft UTID December 2013
[ISO646] International Organization for Standardization (ISO),
"Information Technology: ISO 7-bit Coded Character Set for
Information Interchange", International Standard, Ref. No.
ISO/IEC 646:1991.
[ISO8402] International Organization for Standardization. ISO 8402:
1994: Quality Management and Quality Assurance-Vocabulary.
International Organization for Standardization, 1994.
[RFC1034] P. Mockapetris, "Domain names - concepts and facilities",
IETF RFC1034, Internet Eng. Task Force, Jan. 1987;
www.ietf.org/rfc/rfc1034.txt.
[RFC1035] P. Mockapetris, "Domain names - implementation and
specification", IETF RFC1035, Internet Eng. Task Force, Jan.
1987; www.ietf.org/rfc/rfc1035.txt.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] T. Berners-Lee, RT Fielding, and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", IETF RFC3986
(standards track), Internet Eng. Task Force, Jan. 2005;
www.ietf.org/rfc/rfc3986.txt.
[RFC5234] D. Crocker, Ed., "Augmented BNF for Syntax Specifications:
ABNF", IETF RFC5234 (standards track), Internet Eng. Task
Force, Jan. 2008; www.ietf.org/rfc/rfc5234.txt.
[STD63] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[Unicode] Julie D. Allen. The Unicode Standard, Version 6.0, The
Unicode Consortium, Mountain View, 2011.
10.2. Informative References
[Huang2011] Neng-Geng Huang, Bing-Liang Zhang, Zhi-Yuan Huang (2011):
"Concept and design of a things mail system", Signal
Processing, Communications and Computing (ICSPCC), 2011 IEEE
International Conference on. DOI: 10.1109/ICSPCC.2011.6061741
[I-D-IDTP] N. G. Huang, "Identifier Tracing Protocol (IDTP)",
Internet-Draft, draft-huangng-idtp-01.txt, Dec. 2013.
N. G. Huang Expires June 2, 2014 [Page 16]
Internet-Draft UTID December 2013
11. Acknowledgments
The author of this document thanks to Mr. Zhang Bing-Liang for his
innovative idea of things mail that inspired the concept of UTID and
IDTP.
This document was prepared using 2-Word-v2.0.template.dot.
N. G. Huang Expires June 2, 2014 [Page 17]
Internet-Draft UTID December 2013
Appendix A. Parsing a UTID with a Regular Expression
The following line is the regular expression for breaking-down a
UTID into its components.
^(([\u0021-\u007e\u0080-\uffff]{1,92})??)(~([a-z0-9][a-z0-9\-
\.]{0,30}[a-z0-9]?)?)(@([a-z0-9][a-z0-9\-\.]{0,30}[a-z0-
9]?)?)(\$([a-z0-9][a-z0-9\-\.]{0,60}\.[a-z]{2,7}))$
For example, matching the above expression to
123~cat@loc$abc.example
results in the following sub expression matches:
$1 = 123
$2 = 123
$3 = ~cat
$4 = cat
$5 = @loc
$6 = loc
$7 = $abc.example
$8 = abc.example
Therefore, we can determine the value of the four components as:
id = $2
catalog = $4
location = $6
dns = $8
When above regular expression is used, a UTID that does not have
delimiters of '~' or '@' should be add '~' or '@' prior to matching.
For example, a UTID of '123$abc.example' should be converted into
'123~@$abc.example' before matching and the result would be:
N. G. Huang Expires June 2, 2014 [Page 18]
Internet-Draft UTID December 2013
$0 = 123~@$abc.example
$1 = 123
$2 = 123
$3 = ~
$4 = null
$5 = @
$6 = null
$7 = $abc.example
$8 = abc.example
Therefore, we can determine the value of the four components as:
id = $2
catalog = $4 ; null (convert to empty)
location = $6 ; null (convert to empty)
dns = $8
N. G. Huang Expires June 2, 2014 [Page 19]
Internet-Draft UTID December 2013
Appendix B. Delimiting a UTID in Context
UTIDs are usually transmitted through formats that provide a clear
context for their interpretation. However, it is important to be
able to delimit the UTID from the rest of the text if a UTID is in a
plain text file for printing or transmitting. In such case, UTIDs
are delimited by double-quotes is recommended. For example,
"123@loc$abc.example" is a UTID.
Copyright (c) 2013 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
N. G. Huang Expires June 2, 2014 [Page 20]
Internet-Draft UTID December 2013
Authors' Addresses
Neng Geng Huang
School of the Internet of Things
Wuxi Institute of Technology
Wuxi, Jiangsu,
China, 214121
Phone: 86-13921501950
Email: huangng@gmail.com
N. G. Huang Expires June 2, 2014 [Page 21]