DOCUM: From the document point of view, it seems logical just to
provide for a text tag. Users or applications could easily come
up with short readable tags. These would probably be meaningful
to a person if humanly generated (e.g., "Susan") and at least
fairly short and systematic if automatically generated (e.g.,
"A123"). The ID attribute type in XML [XML] appears to have been
thought of this way, although it can be used in other ways.
PROTO: From a protocol point of view, unique internal labels look
very different than they do from a document point of view. Since
this point of view assumes that pieces of different protocol
messages will later be combined in a variety of ways, previously
unique labels can conflict. There are really only three
possibilities if such tags are needed, as follows:
(1) Have a system for dynamically rewriting such tags to maintain
uniqueness. This is usually a disaster, as it (a) invalidates
any stored copies of the tags that are not rewritten, and it
is usually impossible to be sure there aren’t more copies
lurking somewhere you failed to update, and (b) invalidates
digital signatures that cover a changed tag.
(2) Use some form of hierarchical qualified tags. Thus the total
tag can remain unique even if a part is moved, because its
qualification changes. This avoids the digital signature
problems described above. But it destroys the concept of a
globally-unique anchor embedded in and moving with the data.
And stored tags may still be invalidated by data moves.
Nevertheless, within the scope of a particular carefully
designed protocol, such as IOTP [RFC2801], this can work.
(3) Construct a lengthy globally-unique tag string. This can be
done successfully by using a good enough random number
generator and big enough random tags (perhaps about 24
characters) sequentially, as in the way email messages IDs are
created [RFC2822].
Thus, from a protocol point of view, such tags are difficult but
if they are needed, choice 3 works best.
3. Examples
IETF protocols are replete with examples of the protocol viewpoint
such as TCP [RFC793], IPSEC [RFC2411], SMTP [RFC2821], and IOTP
[RFC2801, RFC2802].
The eXtensible Markup Language [XML] is an example of something that
can easily be viewed both ways and where the best results frequently
require attention to both the document and the protocol points of
view.
Computerized court documents, human-to-human email, and the X.509v3
Certificate [X509v3], particularly the X509v3 policy portion, are
examples primarily designed from the document point of view.
4. Resolution of the Points of View
There is some merit to each point of view. Certainly the document
point of view has some intuitive simplicity and appeal and is OK for
applications where it meets needs.
The protocol point of view can come close to encompassing the
document point of view as a limiting case. In particular, it does so
under the following circumstances:
1. As the complexity of messages declines to a single payload
(perhaps with a few attachments).
2. As the mutability of the payload declines to some standard format
that needs little or no canonicalization.
3. As the number of parties and amount of processing declines as
messages are transferred.
4. As the portion of the message intended for more or less direct
human consumption increases.
Under the above circumstances, the protocol point of view would be
narrowed to something quite close to the document point of view.
Even when the document point of view is questionable, the addition of
a few options to a protocol will usually mollify the perceived needs
of those looking at things from that point of view. For example,
adding optional non-canonicalization or an optional policy statement,
or inclusion of semantic labels, or the like.
On the other hand, the document point of view is hard to stretch to
encompass the protocol case. From a strict piece of paper
perspective, canonicalization is wrong; inclusion of human language
policy text within every significant object and a semantic tag with
every adjunct should be mandatory; and so on. Objects designed in
this way are rarely suitable for protocol use, as they tend to be
improperly structured to accommodate hierarchy and complexity,
inefficient (due to unnecessary text and self-documenting
inclusions), and insecure (due to brittle signatures).
Thus, to produce usable protocols, it is best to start with the
protocol point of view and add document point of view items as
necessary to achieve consensus.
5. Conclusion
I hope that this document will help explain to those of either point
of view where those with the other view are coming from. It is my
hope that this will decrease conflict, shed some light -- in
particular on the difficulties of security design -- and lead to
better protocol designs.
6. Security Considerations
This document considers the security implications of the Document and
Protocol points of view, as defined in Sections 2.1 and 2.2, and
warns of the security defects in the Document view. Most of these
security considerations appear in Section 2.4 but they are also
touched on elsewhere in Section 2 which should be read in its
entirety.
Informative References
[ASCII] "USA Standard Code for Information Interchange", X3.4,
American National Standards Institute: New York, 1968.
[ASN.1] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998,
"Information Technology - Abstract Syntax Notation One
(ASN.1): Specification of Basic Notation".
ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
"Information Technology - ASN.1 Encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)". <http://www.itu.int/ITU-
T/studygroups/com17/languages/index.html>.
[CSS] "Cascading Style Sheets, level 2 revision 1 CSS 2.1
Specification", B. Bos, T. Gelik, I. Hickson, H. Lie,
W3C Candidate Recommendation, 25 February 2004.
<http://www.w3.org/TR/CSS21>
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[RFC2801] Burdett, D., "Internet Open Trading Protocol - IOTP
Version 1.0", RFC 2801, April 2000.
[RFC2802] Davidson, K. and Y. Kawatsura, "Digital Signatures for
the v1.0 Internet Open Trading Protocol (IOTP)", RFC
2802, April 2000.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC3076] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March
2001.
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible
Markup Language) XML-Signature Syntax and Processing",
RFC 3275, March 2002.
[RFC3741] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[X509v3] "ITU-T Recommendation X.509 version 3 (1997),
Information Technology - Open Systems Interconnection -
The Directory Authentication Framework", ISO/IEC 9594-
8:1997.
[XForms] "XForms 1.0", M. Dubinko, L. Klotz, R. Merrick, T.
Raman, W3C Recommendation 14 October 2003.
<http://www.w3.org/TR/xforms/>
[XML] "Extensible Markup Language (XML) 1.0 Recommendation
(2nd Edition)". T. Bray, J. Paoli, C. M. Sperberg-
McQueen, E. Maler, October 2000.
<http://www.w3.org/TR/2000/REC-xml-20001006>
[XMLENC] "XML Encryption Syntax and Processing", J. Reagle, D.
Eastlake, December 2002.
<http://www.w3.org/TR/2001/RED-xmlenc-core-20021210/>
Author’s Address
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Phone: +1 508-786-7554 (w)
+1 508-634-2066 (h)
Fax: +1 508-786-7501 (w)
EMail: Donald.Eastlake@motorola.com
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and at www.rfc-editor.org, and except as set
forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the ISOC’s procedures with respect to rights in ISOC Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.