You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some TSPs provide messaging addressed to vehicles, others provide messaging addressed to drivers.
The motor freight carrier feedback we have received is that motor freight carriers prefer messaging addressed to drivers.
While it is evidently true that TSPs have fundamentally different architectures for messaging drivers (to-vehicle vs. to-driver), it is also true that OTAPI must provide an interface that will enable motor freight carrier code to be portable. OTAPI does need to support both. The degree to which it is supported to is to enable 1) the TSPs to implement either to-vehicle or to-driver but also to allow motor freight carriers code to satisfy their messaging use cases regardless of which way the TSP implemented it...
It comes down to how carriers initiate the process of sending a message for display somehwere in their fleet. Do they start with a Driver, a Vehicle or are both starting points valid?
Also, we have the notion now of 'partial support' of OTAPI in responses to the use cases questionnaire. If it is the case that both starting points are valid then we will need to capture both use cases in the questionnaire and leave it up to TSPs to answer which mode is supported.
The text was updated successfully, but these errors were encountered:
BenGardiner
added
blocked
waiting for something else to finish before this is ready to tackle
and removed
attention wanted
Extra attention is needed: opinions, questions, changes, anything
blocked
waiting for something else to finish before this is ready to tackle
labels
May 29, 2019
Some TSPs provide messaging addressed to vehicles, others provide messaging addressed to drivers.
The motor freight carrier feedback we have received is that motor freight carriers prefer messaging addressed to drivers.
While it is evidently true that TSPs have fundamentally different architectures for messaging drivers (to-vehicle vs. to-driver), it is also true that OTAPI must provide an interface that will enable motor freight carrier code to be portable. OTAPI does need to support both. The degree to which it is supported to is to enable 1) the TSPs to implement either to-vehicle or to-driver but also to allow motor freight carriers code to satisfy their messaging use cases regardless of which way the TSP implemented it...
It comes down to how carriers initiate the process of sending a message for display somehwere in their fleet. Do they start with a Driver, a Vehicle or are both starting points valid?
Also, we have the notion now of 'partial support' of OTAPI in responses to the use cases questionnaire. If it is the case that both starting points are valid then we will need to capture both use cases in the questionnaire and leave it up to TSPs to answer which mode is supported.
The text was updated successfully, but these errors were encountered: