home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / X / mit / doc / Registry / README next >
Encoding:
Text File  |  1991-07-17  |  4.7 KB  |  126 lines
  1.                   X Registry
  2.  
  3. The MIT X Consortium is maintaining a registry of certain X-related items, to
  4. aid in avoiding conflicts and to aid in sharing of such items.  Requests to
  5. register items, or questions about registration, should be addressed to
  6.     xregistry@expo.lcs.mit.edu
  7. or to
  8.     Bob Scheifler
  9.     Laboratory for Computer Science
  10.     545 Technology Square
  11.     Cambridge, MA 02139
  12.  
  13. Electronic mail will be acknowledged upon receipt.  Please allow up to 4 weeks
  14. for a formal response to registration and inquiries.
  15.  
  16. The registry is published as part of the X software distribution from MIT.
  17. It is also usually available by sending a message to xstuff@expo.lcs.mit.edu.
  18. The message can have a subject line and no body, or a single-line body and
  19. no subject, in either case the line looking like:
  20.     send docs registry
  21.  
  22. All registered items must have the postal address of someone responsible for
  23. the item, or a reference to a document describing the item and the postal
  24. address of where to write to obtain the document.
  25.  
  26. Registration of conflicting items will not be permitted (the same value will
  27. not be assigned two different meanings) except where explicitly indicated.
  28.  
  29. Items in the following categories are acceptable for registration:
  30.  
  31. Organization names
  32.     These should generally be used as prefixes for other registered names.
  33.     Examples: "MIT"; "X3D".
  34.  
  35. Keysyms (name, value, #define'd name in C, other languages)
  36.     Only "private" keysyms (with 29th bit set) can be registered by
  37.     organizations; standard keysyms must be approved by the Consortium.
  38.     Since keysym numeric values are explicitly private, we will permit
  39.     (but not encourage) conflicting registration here.
  40.  
  41. Authorization protocol names
  42.     See Section 8 of the protocol.  Names should generally have an
  43.     organizational prefix.  Examples: "MIT-MAGIC-COOKIE-1";
  44.     "MIT-KERBEROS-5".
  45.  
  46. Vendor string formats
  47.     See Section 8 of the protocol.  The vendor string should generally have
  48.     an organizational prefix.  Example: "MIT X Consortium".
  49.  
  50. Protocol extension names
  51.     As used in the QueryExtension and ListExtensions protocol requests.
  52.     The name should generally have an organizational prefix.  Example:
  53.     "X3D-PEX".
  54.  
  55. Host Families
  56.     See the "family" component of the HOST structure in the protocol.
  57.     Values for private families will be assigned by MIT.  Examples: Starlan
  58.     address; OSI address; hostname string
  59.  
  60. Property names
  61.     As stored on windows in the server.  See Sections 4.1.2, 4.1.3, 5.1.1,
  62.     and 6.4 of the ICCCM, and Section 14.1 of the Xlib manual.
  63.     Registration must include the context in which the property is used
  64.     (e.g. root window, top-level client window).  In general, private
  65.     property names should start with a leading underscore, followed by the
  66.     organizational prefix, followed by another underscore.
  67.  
  68. Property type names
  69.     See "Property names" above.
  70.  
  71. Selection names
  72.     See Section 2.6.1 of the ICCCM.  In general, private selection names
  73.     should start with a leading underscore, followed by the organizational
  74.     prefix, followed by another underscore.
  75.  
  76. Selection targets
  77.     See Section 2.6.2 of the ICCCM.  In general, private selection targets
  78.     should start with a leading underscore, followed by the organizational
  79.     prefix, followed by another underscore.
  80.  
  81. WM_PROTOCOLS protocols
  82.     See Section 4.1.2.7 of the ICCCM.  In general, private protocols should
  83.     start with a leading underscore, followed by the organizational prefix,
  84.     followed by another underscore.
  85.  
  86. ClientMessage types
  87.     See the "type" field in the ClientMessage event in the protocol, and
  88.     Section 4.2.8 of the ICCCM.  In general, private types should start
  89.     with a leading underscore, followed by the organizational prefix,
  90.     followed by another underscore.
  91.  
  92. Font Foundry names
  93.     See Section 3.1.2.1 of the XLFD.  This will typically be an
  94.     organization name.
  95.  
  96. Font CharSet (Registry and Encoding) names
  97.     See Sections 3.1.2.13 and 3.1.2.14 of the XLFD.  For ISO standards, the
  98.     format will generally be:
  99.         "ISO" + <standard-number> + "-" + <part-number>
  100.     Example: "ISO8859-1".
  101.  
  102. Font Property names
  103.     See QueryFont in the protocol, and Section 3.2 of the XLFD.  In
  104.     general, private properties should start with a leading underscore,
  105.     followed by the organizational prefix, followed by another underscore.
  106.  
  107. Resource types
  108.     See Chapter 15 of the Xlib manual and Section 9.1 of the Xt manual.
  109.  
  110. Application classes
  111.     See Section 4.1.2.5 of the ICCCM and Section 14.1.8 of the Xlib manual.
  112.     [Only class names, not instance names.]
  113.  
  114. Class extension record types
  115.     See Section 1.4.12 of the Xt Intrinsics manual.
  116.  
  117. Display Manufacturer ID
  118.     See Section 9 of the X Display Manager Control Protocol.
  119.  
  120. Non-Standard Character Set Encodings for Compound Text
  121.     See Section 6 of the Compound Text standard.
  122.  
  123. PEX Vendor ID
  124.     For identifying GDPs, GSEs, enum values/types, OC types, table types.
  125.     See PEX 5.0 interoperability conventions.
  126.