Elizabeth Sall

Since this is a "best practice" and not in the spec itself (I think), suggest making this a `warning` not an `error`.

Agreed with above @barbeau. I updated the labels to reflect the need to clarify the spec (and BP) respectfully.

Relevant [Best Practice](https://gtfs.org/realtime/best-practices/): > The server hosting GTFS Realtime data should be reliable and consistently return validly-formatted protobuf-encoded responses. Fewer than 1% of responses should be invalid (protobuf errors or...

For this (and a few other rules, e.g. the ones related to id stability) I'm wondering if a monitoring-type functionality needs to be implemented (as opposed to a run-and-done)? This...

Relevant [Best Practice](https://gtfs.org/realtime/best-practices/): > For trips denoted in [`GTFS frequency.txt`](https://gtfs.org/reference/static/#frequenciestxt) as frequency-based by setting exact_times=0 or omitting the exact_times field In [`TripUpdate.StopTimeUpdate`](https://gtfs.org/realtime/best-practices/#StopTimeUpdate), all of `trip_id`, `start_time`, and` start_date` must be...

+1 for me. Should we also consider updating the schema to be consistent? I'm less worried about that, but just something to consider.