1. Motivation

Many products can only be bought or used in some countries. Licensing, export control, payment providers, tax registration and data-protection law all draw geographic lines. A registry that cannot read those lines lists a product to people who cannot buy it, and an AI agent recommends software a user is not allowed to use.

MSR JSON 2.0 carries one geographic value, entity.vendor.country_code. It says where the vendor is based, not where the product is offered. It carries no statement of interface or support languages, none of the currencies a customer can pay in, and none of where customer data is stored. The keys of entity.descriptions look like language tags, but nothing validates them.

2. Schema Extension

RFC 0006 adds an optional capabilities.availability object:

"availability": {
  "regions":            ["019", "150"],
  "countries":          ["AO", "MZ"],
  "excluded_countries": ["CU"],
  "languages":          ["pt-BR", "en", "es-419"],
  "support_languages":  ["pt-BR", "en"],
  "currencies":         ["BRL", "EUR", "USD"],
  "data_residency":     ["BR", "EU"]
}

Every field is optional, and at least one must be present when the object is present. Every list is non-empty and holds no duplicates. Unknown keys are rejected.

The accepted region codes are 001 (World), the continents 002 Africa, 019 Americas, 142 Asia, 150 Europe and 009 Oceania, and their CLDR sub-regions (for example 419 Latin America and the Caribbean, 005 South America, 003 North America). A three-digit M49 country code is not a region and is rejected; countries use ISO 3166-1. The exceptionally reserved code EU is accepted for the European Union. Europe (150) is not the same legal perimeter as the EU.

languages and support_languages are independent: a product with an interface in ten languages may answer support tickets in two. currencies lists every currency a customer can be billed in; pricing.currency stays the currency of the advertised price.

The same draft also constrains the keys of entity.descriptions to BCP 47 language tags.

3. Semantics

1. Absent means not declared, never worldwide. A registry MUST NOT treat a manifest without regions or countries as available everywhere. A publisher that means worldwide declares "regions": ["001"].
2. The offered set is the union of the countries contained in regions and those in countries, minus excluded_countries. Exclusion wins over inclusion.
3. Region containment is resolved with the Unicode CLDR territory containment data, not with a list maintained by this specification.
4. Where the product is offered and where data lives are separate statements. A product offered worldwide may keep all data in one country. Registries SHOULD offer separate filters for the two.
5. These are claims the publisher makes about its own product. They carry the same weight as the manifest's other claims and no more. data_residency is not a compliance certification.

4. Compatibility

MSR JSON 2.0 closes capabilities with additionalProperties: false. Adding the object to 2.0 would make a 2.0 validator reject manifests that use it. The change therefore lives in the v2.1 draft schema only. No 2.0 manifest changes meaning, and no 2.0 validator changes behavior.

5. Security and Privacy Considerations

• A false data_residency claim can mislead buyers with legal obligations. Registries SHOULD show it as a publisher claim, and SHOULD show whether the manifest is signed (RFC 0003).
• The fields describe a product, never a person. They hold no personal data.
• Consumers MUST validate codes against the schema before using them in queries, so an invalid code cannot reach a registry's filter or search layer.