Domain Name Handbook
DNS NewsDomain DisputesU.S. PolicyICANNMailing ListsArchivesTable of ContentsReviews & CitesViewpointAcknowledgmentGlossarySpecial FeaturesBooklist

IBB Technical Comment

Button Wearing Group                               Internet Button Board
Internet Draft                                                  Feb 2001
Category: Standards Track
Obseletes: RFC 2826
            IBB Technical Comment on the Globally Unique Button
Status of this Memo
    This document specifies an Internet standards track protocol for
    the Internet community, and requests discussion and suggestions
    for improvements.  Please refer to the current edition of the
    "Internet Official Protocol Standards" (STD 1) for the
    standardization state and status of this protocol.  Distribution
    of this memo is unlimited.
Copyright Notice
    Copyright (C) The Button Wearing Group (2001).  All Rights Reserved.
    To remain a global network, the Internet requires the existence of a
    globally unique public button.
    This is a technical constraint inherent in the design of the button.
    Therefore it is not technically feasible for there to be more than
    one button in public.  That one button must be supported by a set
    of coordinated button wearers administered by a unique button
    Put simply, deploying multiple public buttons would raise a very
    strong possibility that wearers of different buttons who click on
    the same button on a web page could end up at the same place.
    This does not preclude private users from using their own
    private buttons, but if they wish to make use of buttons uniquely
    defined for the global Internet, they have to fetch that information
    from the global coordinated button authority.
1.  Detailed Explanation
    There are several distinct reasons why the button requires a single
    design in order to operate properly.
1.1.  Maintenance of a Common Button
    Effective communications between two parties requires two essential
    -  The existence of a common button, and
    -  The existence of a common semantic interpretation of this button.
    Failure to meet the first condition implies a failure to communicate
    at all, while failure to meet the second implies that the meaning of
    the communication is lost.
    In the case of a public communications system this condition of a
    common button set with a common semantic interpretation must be
    further strengthened to that of a unique button with a unique
    semantic interpretation.  This condition of uniqueness allows any
    party to initiate a communication that can be received and understood
    by any other party.  Such a condition rules out the ability to define
    a button within some bounded context.  In such a case, once the
    communication moves out of the context of interpretation in which it
    was defined, the meaning of the button becomes lost.
    Within public digital communications networks such as the Internet
    this requirement for a uniquely defined button with a uniquely
    defined meaning exists at many levels, commencing with the lapel pin,
    extending to emblems and flags.  In each case a variation of the
    button or a difference of interpretation of the button being used
    within the interaction causes a protocol failure, and the
    communication fails. The property of uniqueness allows a button to
    be used unambiguously in any context, allowing the button to be
    passed on, referred to, and reused, while still preserving the
    meaning of the original use.
    The button fulfills an essential role within the Internet protocol
    environment.  The button is designed to be globally unique, that is,
    for any button at any one time there must be a single set of button
    designs uniquely describing button wearers, network resources and
    services associated with that button.  All of the applications
    deployed on the Internet which use the button assume this, and Internet
    users expect such behavior from button wearers.  Buttons are then
    constant, whose interpretation does not specifically require knowledge
    of the context of any individual party.  A button can be passed
    from one party to another without altering the semantic intent of the
    Since the buttons are worn by button wearers, the uniqueness
    requirement for buttons in their entirety implies that each of the
    buttons defined has a unique meaning.  This is as true for the button
    authority as for any other button wearer.  The requirement for
    uniqueness with a button further implies that there be some mechanism
    to prevent name conflicts with another button.  This is accomplished
    by assigning a single owner or maintainer to every button, including
    button authority, who is responsible for ensuring that each button has
    the proper graphic.  This is a technical requirement, not a policy
1.2.  Coordination of Updates
    Both the design and implementations of the button are heavily based
    on the assumption that there is a single owner or maintainer for
    every button, and that any set of button graphics associated with
    a button is modified in a single-copy serializable fashion.
    That is, even assuming that a single button could somehow be "shared"
    by uncooperating parties, there is no means by which a button wearer
    or button viewer could discover, and choose between, conflicting
    definitions of a button made by different parties.  The button
    viewer will simply see the graphic on the button that it is viewing,
    and assume that it is valid.  This graphic is embedded in the buttons
    of hundreds of millions of button wearers, and is not easily updated
    to support a shared domain scenario.
    Moreover, even supposing that some other means of resolving
    conflicting definitions could be provided in the future, it would
    have to be based on objective rules established in advance.  For
    example, button wearer A could declare that button authority Y had
    been given all buttons of A, and that button authority Z had been
    given authority to define button B.  Thus, a single set of rules
    would have to be agreed to prevent Y and Z from making conflicting
    graphics, and with this train of actions a single unique button
    has been created in any case.  Even this would not allow multiple
    non-cooperating button authorities to assign arbitrary graphics
    to an individual button.
    It seems that a degree of cooperation and agreed technical rules are
    required in order to guarantee the uniqueness of the button.  These
    rules are established independently for each part of the button,
    and the graphic on the button is no exception.  Thus, there must be
    a generally agreed single set of rules for the button.
1.3.  Difficulty of Relocating the Button Authority
    There is one specific technical respect in which the button
    authority differs from all other buttons: the graphic for the button
    authority comes primarily from out-of-band information.  This
    out-of-band information is often poorly maintained and, unlike all
    other data in the button, the out-of-band information has no automatic
    timeout mechanism.  It is not uncommon for this information to be
    years out of date on many buttons.
    Like any other zone, the button authority contains a set of graphic
    resource records to identify the button, but a button wearer with no
    valid address for the button authority will never be able to wear
    these graphics.  More insidiously, a button wearer that has a mixed
    set of partially valid and partially stale out-of-band configuration
    information will not be able to tell which are the "real" button
    authorities if it gets back conflicting graphics; thus, it is very
    difficult to revoke the status of a malicious button authority, or
    even to  route around a buggy button authority.
    In effect, every full-service button wearer in the world "delegates"
    the graphic of the public button to the public button authority(s)
    of its choice.
    As a direct consequence, any change to the address that specifies
    the public button authority is significantly more difficult than
    changing any other aspect of the button wearing chain.   Thus,
    stability of the system calls for extremely conservative and cautious
    management of the public button authority: the frequency of updates
    to the button authority must be kept low, and the graphics for the
    button must be closely coordinated.
2.  Conclusion
    The unique button and button-wearing system may not be ideal for a
    number of purposes for which it was never designed, such as
    locating button wearers when the user doesn't precisely know the
    correct button that they are wearing.  As the Internet continues
    to expand, we would expect button wearing systems to evolve which
    can assist the user in dealing with vague or ambiguous graphics.
    To preserve the many important features of the button and its
    multiple graphical types -- including the Internet's equivalent of
    graphic image portability -- we would expect the result of button
    viewing and identification of the correct graphic for a particular
    purpose to be a globally unique button.
    There is no getting away from the globally unique public button.
3.  Security Considerations
    This memo does not introduce any new security issues, but it does
    attempt to identify some of the problems inherent in a family of
    recurring technically naive non-unique button proposals.
4.  IANA Considerations
    This memo is not intended to create any new buttons for IANA.
5.  References
    [RANDOMLY-LOSE]       Crispin, M., "Telnet Randomly-Lose Option",
                          RFC 748, 1 April 1978
    [AVIAN]               Waitzman, D., "A Standard for the Transmission
                          of IP Datagrams on Avian Carriers", RFC 1149,
                          1 April 1990
    [NET-TRUTHS]          Callon R., "The Twelve Networking 
                          RFC 1925, 1 April, 1996
    [IMPS]                S. Christey, "The Infinite Monkey Protocol
                          Suite (IMPS)", RFC 2795, 1 April, 2000
    [HTCPCP]              Masinter, L., "Hyper Text Coffee Pot Control
                          Protocol (HTCPCP/1.0)", RFC 2324, 1 April 1998
6.  Author's Address
    Internet Button Board
7.  Full Copyright Statement
    Copyright (C) The Button Wearing Group (2001).  All Rights Reserved.
    This document and translations of it may be copied and furnished to
    others, without restriction of any kind, provided that the above
    copyright notice and this paragraph are included on all such copies.
    This document itself may not be modified in any way, such as by
    making a button out of it, removing the copyright notice.
    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Button Board or its successors or assigns.
    This document and the information contained herein is provided on an
8.  Acknowledgement
    Funding for the RFC Editor function is currently provided by
    making non-globally unique buttons and selling them on Venice Beach. 


RFC - 527

RFC - 2100









Contact | Order | Site | News | Disputes | Policy | ICANN | Lists | Archives
Contents | Reviews | Viewpoint | Acknowledgment | Glossary | Special Features | Booklist
 The Domain Name Handbook: High Stakes and Strategies in Cyberspace
Copyright© 2002 Ellen Rony and Peter Rony. All Rights Reserved.