|
|
|
||
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.
Summary
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
authority.
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
preconditions:
- 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
button.
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
choice.
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
Truths",
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
Email: webmaster@dns-root.org
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
"AS IS" basis and THE INTERNET BUTTON BOARD AND THE BUTTON WEARING
GROUP DISCLAIMS 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.
8. Acknowledgement
Funding for the RFC Editor function is currently provided by
making non-globally unique buttons and selling them on Venice Beach.
|
|
INTERNET HUMOR A |
|
Copyright© 2002 Ellen Rony and Peter Rony. All Rights Reserved. http://www.domainhandbook.com/humor.html |
|||
