E.5 Unique Internal Labels


It is desirable to be able to reference parts of structured messages or objects by some sort of "label," "ID," or "tag." The idea is that this label forms a fixed "anchor" that can be used "globally," at least within an application domain, to reference the tagged part.

PAPER: From the paper point of view, it seems logical to just provide for a text tag, so that users or applications could easily come up with short, readable tags. These tags would probably be meaningful to a person if generated by humans (i.e., "Susan") and at least fairly short and systematic if generated automatically (i.e., "A123"). The ID attribute type in XML [XML] appears to have been thought of this way, although it can be used in other ways.

PROTOCOL: From a protocol point of view, unique internal labels look very different than they do from a paper point of view. You should assume that pieces of different protocol messages will later be combined in a variety of ways, so that previously unique labels can conflict. Only three possibilities exist if you need such tags:

  1. Have a system for dynamically rewriting such tags to maintain uniqueness. This tactic is usually a disaster, for two reasons:

    1. It invalidates any stored copies of the tags that are not rewritten. It is usually impossible to ensure that more copies aren't lurking somewhere that you failed to update.

    2. It invalidates digital signatures that cover a changed tag.

  2. Use some form of hierarchical qualified tags. With this approach the total tag can remain unique even if a part is moved, because its qualification changes. This strategy avoids the digital signature problems of the first approach, but it damages the concept of a globally unique anchor embedded in and moving with the data. Also, stored tags may still be invalidated by data moves. Nevertheless, within a particular carefully designed protocol, such as IOTP [RFC 2801], this tactic can work.

  3. Construct a lengthy, globally unique tag string. This can be done successfully in one of two ways:

    1. By using a good-enough random number generator and big-enough random tags

    2. More sequentially, similar to the way e-mail message IDs are created [RFC 2822]

From a protocol point of view, such tags are difficult. If you really need them, however, the third choice works best.



Secure XML(c) The New Syntax for Signatures and Encryption
Secure XML: The New Syntax for Signatures and Encryption
ISBN: 0201756056
EAN: 2147483647
Year: 2005
Pages: 186

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net