DataMuseum.dk

top - metrics - download

    Length: 4839 (0x12e7)
    Types: TextFile
    Names: »README«

└─⟦276d19d6e⟧ Bits:30007243 EUUGD5_I: X11R5
    └─⟦4856bf7e7⟧ »./mit-4/mit-4.00« 
        └─⟦635ff9e7e⟧ 
            └─⟦this⟧ »mit/doc/Registry/README« 

TextFile

				  X Registry

The MIT X Consortium is maintaining a registry of certain X-related items, to
aid in avoiding conflicts and to aid in sharing of such items.  Requests to
register items, or questions about registration, should be addressed to
	xregistry@expo.lcs.mit.edu
or to
	Bob Scheifler
	Laboratory for Computer Science
	545 Technology Square
	Cambridge, MA 02139

Electronic mail will be acknowledged upon receipt.  Please allow up to 4 weeks
for a formal response to registration and inquiries.

The registry is published as part of the X software distribution from MIT.
It is also usually available by sending a message to xstuff@expo.lcs.mit.edu.
The message can have a subject line and no body, or a single-line body and
no subject, in either case the line looking like:
	send docs registry

All registered items must have the postal address of someone responsible for
the item, or a reference to a document describing the item and the postal
address of where to write to obtain the document.

Registration of conflicting items will not be permitted (the same value will
not be assigned two different meanings) except where explicitly indicated.

Items in the following categories are acceptable for registration:

Organization names
	These should generally be used as prefixes for other registered names.
	Examples: "MIT"; "X3D".

Keysyms (name, value, #define'd name in C, other languages)
	Only "private" keysyms (with 29th bit set) can be registered by
	organizations; standard keysyms must be approved by the Consortium.
	Since keysym numeric values are explicitly private, we will permit
	(but not encourage) conflicting registration here.

Authorization protocol names
	See Section 8 of the protocol.  Names should generally have an
	organizational prefix.  Examples: "MIT-MAGIC-COOKIE-1";
	"MIT-KERBEROS-5".

Vendor string formats
	See Section 8 of the protocol.  The vendor string should generally have
	an organizational prefix.  Example: "MIT X Consortium".

Protocol extension names
	As used in the QueryExtension and ListExtensions protocol requests.
	The name should generally have an organizational prefix.  Example:
	"X3D-PEX".

Host Families
	See the "family" component of the HOST structure in the protocol.
	Values for private families will be assigned by MIT.  Examples: Starlan
	address; OSI address; hostname string

Property names
	As stored on windows in the server.  See Sections 4.1.2, 4.1.3, 5.1.1,
	and 6.4 of the ICCCM, and Section 14.1 of the Xlib manual.
	Registration must include the context in which the property is used
	(e.g. root window, top-level client window).  In general, private
	property names should start with a leading underscore, followed by the
	organizational prefix, followed by another underscore.

Property type names
	See "Property names" above.

Selection names
	See Section 2.6.1 of the ICCCM.  In general, private selection names
	should start with a leading underscore, followed by the organizational
	prefix, followed by another underscore.

Selection targets
	See Section 2.6.2 of the ICCCM.  In general, private selection targets
	should start with a leading underscore, followed by the organizational
	prefix, followed by another underscore.

WM_PROTOCOLS protocols
	See Section 4.1.2.7 of the ICCCM.  In general, private protocols should
	start with a leading underscore, followed by the organizational prefix,
	followed by another underscore.

ClientMessage types
	See the "type" field in the ClientMessage event in the protocol, and
	Section 4.2.8 of the ICCCM.  In general, private types should start
	with a leading underscore, followed by the organizational prefix,
	followed by another underscore.

Font Foundry names
	See Section 3.1.2.1 of the XLFD.  This will typically be an
	organization name.

Font CharSet (Registry and Encoding) names
	See Sections 3.1.2.13 and 3.1.2.14 of the XLFD.  For ISO standards, the
	format will generally be:
	    "ISO" + <standard-number> + "-" + <part-number>
	Example: "ISO8859-1".

Font Property names
	See QueryFont in the protocol, and Section 3.2 of the XLFD.  In
	general, private properties should start with a leading underscore,
	followed by the organizational prefix, followed by another underscore.

Resource types
	See Chapter 15 of the Xlib manual and Section 9.1 of the Xt manual.

Application classes
	See Section 4.1.2.5 of the ICCCM and Section 14.1.8 of the Xlib manual.
	[Only class names, not instance names.]

Class extension record types
	See Section 1.4.12 of the Xt Intrinsics manual.

Display Manufacturer ID
	See Section 9 of the X Display Manager Control Protocol.

Non-Standard Character Set Encodings for Compound Text
	See Section 6 of the Compound Text standard.

PEX Vendor ID
	For identifying GDPs, GSEs, enum values/types, OC types, table types.
	See PEX 5.0 interoperability conventions.