You are currently viewing a snapshot of taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to, please file a bug.

Plugin Identifier Specification


Plugin ID Definition

A Plugin ID (PLID) is a string in URI format that identifies a plugin uniquely.
A PLID takes this format:


The special symbols are @, / and ,. A PLID begins with an @Domain, followed by a "/", then a ProductName,  a "," (comma) and version=version number. The PLID is a unique identifier for plugin modules, and on Win32, form the basis for registry keys (see First Install Problem write-up).

Key To Above Definition

* -- Optional -- Zero or more can be present
? -- One or more are required
[string] -- Vendor determines the pattern the *string* may take

Breakdown of a Plugin ID (PLID)

  • Mandatory: @Domain
    The @Domain part of the PLID can consist of a '@' symbol and a Domain Name (e.g. or Domain Names are generally unique, and are a suitable means to identify the parent company that makes the plugin. An example might be But the @Domain does not necessarily have to be a domain name. It can be any string, so long as it follows URI convention. Another example: . We leave it to the vendor to decide whether to use a domain name (in URL style) or some other identifier. See the section on Domain Name Concerns

  • Mandatory: ProductName
    After the "/" separator following the @Domain, the ProductName is a string identifying the product in question. Examples could be MusicPlayer or ReallyOne Player. Since the @Domain and the ProductName are the only two mandatory pieces of information, a valid PLID might be Player

  • Mandatory: version=
    A "," (comma) separator following ProductName is used before version. Version is the vendor-determined versioning mechanism.
    • version=
    •  version=5&Minor=0.0.1
    A full PLID with Version might be: Player,version=

  • Optional: [ModuleIdentifer]
    A PLID is bound to a specific module. But if one application consists of several DLLs, each which handle their own mimetypes, then more than one PLID may be necessary. An example of one "real world" application with more than one DLL for Windows is QuickTime.  each QuickTime DLL handles its own mimetype(s). If, for example, an application has 5 DLLs which handle 5 mimetypes, then that application would have 5 PLIDs. The ModuleIdentifier is just a Vendor-determined string, and can take any form.  A "," (comma) separator follows the version token if the use of ModuleIdentifier is made.  Here are some suggestions:
    Examples of more than one PLID for one application:
    •,version=,MPEG1 where MPEG1 is the ModuleIdentifier, suggesting that this DLL will handle MPEG1 file format.
    •,version=,application/x-fasttime where application/x-fastttime is the ModuleIdentifier, suggesting that this module in the FastTime package handles the mimetype application/x-fasttime.
    The ModuleIdentifier is entirely left to the Vendor to create. Good candidates for this string, however, can be mimetypes (e.g. application/x-fasttime) or general media formats (e.g. MPEG1).  Typically, many applications have one "main" DLL that is always loaded, and thus may not need to get as granular as ModuleIdentifiers.

Domain Name Concerns

A legitimate concern with using domain names bound to real-world URLs might be that companies change, e.g. Company A buys Company B and alters the copyright dynamics of Company B's name. Vendors who wish to insulate themselves from this may choose alternate nomenclature (example: .

Future Directions

Embedders such as CompuServe (who now embed Gecko in lieu of IE as the default browser) can determine on their own the mechanisms to parse the Win32 registry for PLIDs. The Bugzilla bug open on Mozilla and Netscape 6.x is Bug 138363.

Ultimately, the goal is to see this idea work in the context of usage of classid with the OBJECT tag to invoke particular components, instead of arbitrary mimetype-based resolutions.

If every major plugin vendor complies with the writing of plugin directory information into the registry along with a PLID, we can then use the OBJECT tag to invoke plugins based on their "classid" (their respective PLID, which is a URI, which works well with the W3C HTML 4.01 specification for OBJECT). For example, in our case, a prospective invocation might look like:

<object classid=",version=5.01" data="myfile.typ" codebase="" type="application/x-myapp"> </object>
The use of both "type" and "classid" attributes here offers the following user benefit:

  • IF there is another mimetype handler for application/x-myapp, ONLY MyApplication gets invoked. The resolution of a mimetype handler is no longer arbitrary.
  • IF the "data" file myfile.typ doesn't contain enough resource information to load the correct mimetype handling component (DLL), specifying "type" is an additional mechanism.
  • Unlike UUIDs, PLIDs are human readable.

Contact with any further questions.