This section identifies user needs considered but not included in Section 6.3 and the rationale for not including them. 

The initial version of METR does not attempt to address the need for METR users to understand the precise legal meaning and interpretation of a rule; for example, by translating the native language definition (e.g., for a "STOP" sign, "The driver of any vehicle approaching a stop sign at the entrance to, or within, an intersection, shall stop at a limit line, if marked, otherwise before entering the crosswalk on the near side of the intersection. If there is no limit line or crosswalk, the driver shall stop at the entrance to the intersecting roadway or railroad grade crossing.") into an exact electronic structure. The reason for this is multi-fold:
(1) The messaging structure to handle all known scenarios, let alone all possible scenarios, in a readily computer-interpretable format would be overly complex.
(2) The laws are likely often written to create ambiguities in meaning (e.g., one could argue that in the above example, ADS-equipped vehicles are not required to stop since they do not have a driver)
(3) The interpretation of the legal language within laws into practical meanings is often subjective and is within the realm of the judicial process rather than the executive process of a translator.
(4) The effort to define a message format that could capture the full translation of any possible rule definition would likely require substantially more time to standardize.

Future efforts might address areas of known variability within meaning of signs so that systems can be aware of local meanings when significant issues are known. For example, what constitutes a "stopped" vehicle versus a "parked" vehicle; but the initial release of METR will concentrate on identifying the application and distribution of rules rather than the legal definition of the rules.

The initial edition of METR does not attempt to address any specific needs related to aerial drones. While it is expected that the general design of METR will allow for the future addition of rules related to aerial drones, if desired, no specific needs related to these drones are included within this version of the standard.

Indoor pedestrian environments are potentially within the scope of METR but are not a driving justification for it. The initial edition of METR does not attempt to address any needs specific to this environment.

While the general design of METR might allow for its adoption in other environments, METR does not consider any specific needs related to modes of transport beyond those normally covered by intelligent transport systems (ITS). While the exact limits are subject to debate, it generally excludes air transport (above altitudes normally controlled by ground traffic), space transport, intercity rail transport, and sea transport (with the exception of ferries). 

The scope of METR is intended to include all of the rules related to surface transport, as perceived by ISO/TC 204.

METR users include ADS, driver support systems, and humans (e.g., drivers, pedestrians, ancillary users).

Vehicles that support METR need to be able to operate along side vehicles that do not support or are not connected to METR.

Some METR receivers will not be mobile (e.g., PCs used for pre-trip planning).

Sufficient communication bandwidth will be available among the various components of the METR distribution system to support trustworthy METR operations.

All mobile METR receivers will support mobile wireless internet with at least 3G speeds.

Mobile wireless internet connectivity can be unstable for any location.

Mobile wireless internet might not be available at any time in some locations.

All motor vehicles that support METR will support short-range wireless communications meeting local standards (e.g., DSRC, LTE-V2X).

Pre-announced rules will be retrieved at times determined by the METR receiver. This will prevent any requirements for METR receivers to consume energy waiting for broadcasts while also minimizing data loading on the system (e.g., to better ensure every vehicle has the latest rules). 

METR receivers will be notified of relevant ad-hoc rules prior to their need for the rules. For example, the rules could be: 

1. broadcast within the vicinity of the unexpected rule,
2. published to all subscribed receivers in a timely manner, perhaps at a distance from the unexpected rule location.

This document assumes that there may be a desire for a central ITS system to receive METR data and to forward the information to vehicles using other protocols (e.g., TPEG, proprietary). While it is expected that this usage scenario will fade with time, it can provide a practical migration path for many systems.

For example, many vehicle manufacturers have existing communications mechanisms to the vehicles they produce, which including existing ADS-equipped vehicles. In some cases, manufacturers (or others) might update these vehicles with map and rules information using their own mechanisms and revising this interface could be challenging. Nonetheless, the improved trustworthiness of METR will improve safety and liability considerations will encourage manufacturers to adopt METR information. 

Consequently,  manufacturers may wish to process METR information at a central facility and integrate the information into their existing update mechanism (e.g., integrating into their map database) prior to providing the data to their vehicles. An example of how this type of deployment maps to the roles defined in this document is provided in Annex B.3.

Vehicle sensors will be able to correspond map data to the physical world based on GNSS data combined with visual markers (e.g., pavement markings). 

Regulators are responsible for ensuring that the rules distributed by METR promote safe operations.

The dynamic driving task includes the responsibility to provide for the safe operation of the vehicle under all conditions, even in the absence of METR information. For example, the DDT is responsible for detecting a lane closure and responding appropriately even in the absence of METR rule indicating a lane closure. 

For the foreseeable future, METR should be considered as a supplement to existing traffic control devices rather than a replacement of those devices; however, this will likely change over time.

METR needs to be designed to enable efficient data exchanges that do not require frequent downloading of rules that seldom change.

Every version of METR needs to be backwards compatible to support seamless migrations of technology. As such, METR needs to be designed to support forwards compatibility features, such as a version number, the ability to identify protocols used for each METR information category, encryption algorithms used, etc.

The design of METR needs to rely upon existing standards as appropriate (e.g., for interface and data definitions). This should include reuse of existing structures, such as those defined within TN-ITS and TMDD.

METR needs to rely upon existing data sources as appropriate. For example, an emergency vehicle announcing its presence via C-ITS broadcasts can be used to activate rules rather than requiring METR-specific transmissions.

Short range wireless communication channels have limited data capacity, which must be respected while still delivering all applicable rules to transport users. (e.g., this might require the use of short-range wireless messages to notify METR users that more extensive data from central).

The design of METR needs to be flexible enough to support rules for low-altitude aerial drones, although these devices are not directly included in the first edition of this standard.