OpenRoomID Specification

Version 1.0

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119.

Contents

• Abstract
• 1. Problem
• 2. Terminology
• 3. Identifier syntax
• 4. Assignment rules
• 5. Lifecycle
• 6. Resolution and content negotiation
• 7. Governance and permanence commitments
• 8. Security and privacy considerations
• 9. Adoption path
• 10. Registry considerations

Abstract§

This specification defines roomID, a permanent, publicly resolvable identifier for a single hotel accommodation unit: one physical room. It specifies the identifier syntax, the rules under which identifiers are assigned, the lifecycle of an identifier through renumbering, subdivision, property sale, and demolition, and the behavior of the public resolver at openroomid.org. The registry stores identity only. Attributes, pricing, availability, and evidence about rooms are out of scope by design.

1. Problem§

1.1 Categories are sold, units are slept in§

The hotel booking stack transacts on room categories: Deluxe King, Standard Queen, City View. The guest experiences a specific physical unit: room 1412, with its particular window, wall, and neighbor. The mapping from category to unit happens late, inside the property management system, and is invisible to every external system. As a result, no external system can refer to the thing the guest actually receives.

Software that acts on behalf of guests needs referential integrity. A system that selects a particular unit must be able to refer to that unit through discovery, comparison, booking, pre-arrival, the stay, and review, and must be able to refer to the same unit again next year. Today there is no shared identifier for the accommodation unit. Each PMS has internal unit records; none of them are public, portable, or permanent.

1.2 Goal§

OpenRoomID gives every accommodation unit a public, permanent name. The identifier does one job: it lets independent systems agree that they are talking about the same physical room. It carries no judgment about the room and no data beyond identity.

1.3 Out of scope§

The following are deliberately excluded from this specification and from the registry, and MUST NOT be added to either: room attributes (view, bed, layout, noise, condition), quality scores, review counts, rates, availability, transaction state, and evidence or provenance about any of these. Systems that need such data obtain it from commercial providers and join it to the unit by roomID. Keeping the identity layer free of descriptive data is what allows it to remain neutral, free, and permanent.

2. Terminology§

3. Identifier syntax§

3.1 String form§

A unit identifier is three segments joined by hyphens:

7QM4KX92-1412-B

• Property code: exactly 8 characters from the Crockford base32 alphabet, the digits 0 to 9 and the uppercase letters A to Z excluding I, L, O, and U.
• Room designator: 1 to 10 characters from A to Z, a to z, and 0 to 9. Case is preserved as registered and MUST be ignored on lookup. A designator is either the label on the door or a code assigned by the registrar (section 4.2).
• Unit suffix: exactly one uppercase letter A to Z.

The property-only form is the bare property code: 7QM4KX92. The canonical URI form prefixes the scheme rid:, as in rid:7QM4KX92-1412-B.

3.2 ABNF§

rid-uri         = "rid:" ( roomid / property-code )
roomid          = property-code "-" room-designator "-" unit-suffix
property-code   = 8crockford
room-designator = 1*10( ALPHA / DIGIT )
unit-suffix     = %x41-5A                ; A-Z
crockford       = DIGIT / %x41-48        ; A-H
                / %x4A-4B                ; J-K
                / %x4D-4E                ; M-N
                / %x50-54                ; P-T
                / %x56-5A                ; V-Z

3.3 Case and confusable handling§

The canonical form of the property code and the unit suffix is uppercase. Resolvers MUST accept lowercase input and fold it to uppercase. In the property code, resolvers MUST additionally fold the letters I and L to the digit 1 and the letter O to the digit 0, following Crockford base32 decoding practice. The letter U has no fold and is invalid. These folds apply to the property code only; the room designator is a hotel-assigned label, not base32 data, and MUST NOT be remapped.

Room designator lookups are case-insensitive. Registries MUST store the designator in the casing the registrant supplied and MUST reject two registrations within one property whose designator and suffix differ only by case.

4. Assignment rules§

4.1 Property codes§

Property codes are generated by the registrar. They MUST be drawn uniformly at random from the code space and MUST NOT encode meaning of any kind: no sequence, no geography, no brand, no registration date. A property code names the physical property at its location. One property SHALL have at most one active property code.

4.2 Unit identifiers§

Unit identifiers are formed by the registrant from the property code and the property's own room designators. The designator SHOULD be the label a guest would see on the door. The unit suffix for a newly registered unit MUST be A. Subsequent letters are assigned only through the lifecycle events in section 5.

The pair of designator and suffix MUST be unique within a property, compared case-insensitively.

Every unit record states the source of its designator: door or assigned.

Door designators. A unit with a short, stable label on its door SHOULD use that label as its designator, so that anyone in the room can check the identifier against the door.

Assigned designators. A unit whose label is a name, is longer than 10 characters, is absent, or is expected to change SHOULD receive a designator assigned by the registrar. An assigned designator is exactly 4 characters from the Crockford base32 alphabet. The registrar MUST check it against every designator ever used at the property, door or assigned, and MUST NOT reuse it. The property SHOULD display it inside the unit. The operator chooses the source unit by unit.

Names. A unit’s name, such as “The Hemingway Suite,” is display data carried in the record. A change of name MUST NOT change the identifier. Moving a unit from a door designator to an assigned one is a supersession under section 5.2.

4.3 Who may register§

The property operator, or an agent it authorizes, may request identifiers for a property. Assignment is free of charge in all cases (section 7).

4.4 Claims and withdrawal§

A property record is claimed when its current operator has confirmed it, and unclaimed otherwise. A claimed record carries the date the operator last confirmed its unit list. Claims belong to the operator; records belong to the property.

• An operator MAY withdraw its claim at any time. Withdrawal returns the record to unclaimed. It MUST NOT delete, retire, or alter any identifier.
• A change of operator, by sale or otherwise, ends the claim. The identifiers are unaffected. The new operator MAY claim the record by the same process as any operator.
• No party MAY delete a record, including the registrar.

Consumers SHOULD weigh the claim status and the last confirmation date when deciding how far to rely on a record.

4.5 Residences§

When a property is an owner-occupied residence, its public record and the public registry dump MUST NOT include its street address. They carry the locality, region, and country only, and the record is marked residence. The registrar holds the full address privately and uses it only to prevent a second code for the same building. This is the only exception to full publication under section 7.

5. Lifecycle§

5.1 Statuses§

Identifiers are permanent. The registry MUST NOT delete a record, reassign an identifier to a different physical unit, or allow an identifier that has ever resolved to stop resolving.

5.2 Renumbering§

When a property renumbers a room, the physical unit gains a new identifier carrying the new designator, with the next unused suffix for that designator. The old identifier becomes superseded and MUST link to the successor. A system holding the old identifier resolves, follows one 301, and reaches the same physical unit. The supersession chain, not the string, is the durable identity of the physical unit.

5.3 Subdivision and combination§

When one unit is split into two, or two are combined into one, the resulting units are new physical spaces and MUST receive new identifiers. The prior identifiers become retired or superseded.

5.4 Property sale and rebranding§

The property code names the physical property, not its owner, operator, or brand. Sale, franchise change, or renaming MUST NOT change the property code or any unit identifier. The registry updates the display name. A change of operator ends any claim on the record (section 4.4).

5.5 Demolition§

When a property is demolished, its property code and all unit identifiers become retired. They continue to resolve permanently with status retired.

5.6 Identity of the identifier§

6. Resolution and content negotiation§

6.1 Resolver URLs§

Every identifier resolves at https://openroomid.org/{identifier}. The resolver MUST accept the unit form, the property-only form, and the rid: URI form, applying the folds in section 3.3.

6.2 Content negotiation§

A request whose Accept header includes application/ld+json or application/json receives JSON-LD. Any other request receives HTML. Appending .json to the path or the query parameter ?format=json forces JSON regardless of Accept.

6.3 Response semantics§

Every resolver response carries Access-Control-Allow-Origin: *, Cache-Control: public, max-age=3600, and a Link header referencing this specification. The rate limit is 60 requests per minute per IP.

6.4 JSON-LD record§

A registered unit returns a schema.org HotelRoom:

{
  "@context": "https://schema.org",
  "@type": "HotelRoom",
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "roomID",
    "value": "7QM4KX92-1412-B"
  },
  "name": "Room 1412",
  "designatorSource": "door",
  "floorLevel": "14",
  "containedInPlace": {
    "@type": "Hotel",
    "name": "El Cortez Hotel & Casino",
    "identifier": {
      "@type": "PropertyValue",
      "propertyID": "roomID:property",
      "value": "7QM4KX92"
    }
  },
  "status": "active",
  "assigned": "2026-08-14",
  "spec": "https://openroomid.org/spec/1.0"
}

designatorSource is door or assigned (section 4.2). A property code returns a schema.org Hotel whose containsPlace is an array of unit resolver URLs. It also carries claim, either claimed or unclaimed, and, when claimed, lastConfirmed (section 4.4). A residence carries "residence": true and no street address (section 4.5). Records seeded by the registrar for demonstration carry "demo": true.

6.5 Current identifier lookup§

Because supersession chains carry unit identity across renumbering, a resolver client obtains the current identifier for any historical one by following 301 redirects to the end of the chain. Clients SHOULD store the identifier they resolved to, and MAY treat any identifier in a chain as referring to the same physical unit.

7. Governance and permanence commitments§

The registrar operates under the following commitments, which are conditions of the standard rather than promises of convenience:

1. Identifier assignment and resolution are free of charge, for any party, at any volume consistent with the published rate limits. This will not change.
2. The registry never deletes an identifier and never reassigns one to a different physical unit.
3. A published specification version is immutable at its URL. Changes appear only as new versions at new URLs.
4. The resolver requires no authentication, no account, and no key.
5. The registry stores identity only, as defined in section 1.3. The registrar sells nothing. Its founding sponsor, Roomza, Inc., sells products built around the identifier; those products live outside the registry, and the registry MUST NOT privilege any sponsor’s products over anyone else’s.
6. The full registry is exportable: the registrar SHALL publish periodic public dumps of all identifier records, so that the registry can be reconstructed by others if the registrar ceases to operate. Residence street addresses are withheld under section 4.5 and nothing else is.

8. Security and privacy considerations§

Registry records describe buildings, not people. A record MUST NOT contain personal data: no guest information, no staff information, no occupancy state. The assigned date describes the identifier, not any stay.

Identifiers MUST NOT be used to encode occupancy or presence. Publishing that a room exists is harmless; publishing that a person is in it is not, and no field of this standard carries that.

Property codes are random (section 4.1), so the code space reveals nothing about registration order or location. The registry itself is public by design; enumeration of registered identifiers is expected and rate limited rather than prevented.

The resolver is the sole authority for what an identifier names. Systems MUST obtain records over TLS from openroomid.org and SHOULD treat identifier assertions found elsewhere, for example in a hotel's own markup, as claims to verify against the resolver rather than as facts.

9. Adoption path§

The standard is useful before it is universal, and each step below has value on its own:

1. A property registers its property code. Its pages and feeds can now carry one identifier that every system resolves the same way.
2. The property registers its units and adds roomID markup to room-level pages (see the implementation guide).
3. A PMS or channel manager stores the roomID alongside its internal unit record, giving external systems a stable join key.
4. Booking flows carry the identifier through, for example as a rid parameter on booking URLs, so that a selection made upstream survives to assignment.

No hotel has implemented this standard yet. The registry opens with demonstration records only, and this page will not claim otherwise until it is otherwise.

10. Registry considerations§

This section records the registries this standard itself requires, in the manner of an IANA considerations section.

• Status registry: the values active, retired, and superseded. Additions require a new specification version.
• Specification version registry: 1.0, this document. Every version remains available at its own URL permanently.
• Identifier registry: the property and unit records themselves, operated by the registrar under section 7.