nasajoey
commented
5 years ago A USS is against spec if it doesn't provide a valid URL that provides the information it is supposed to provide. So I think the current spec is sufficient:
description: >-
A base URL that the receiver would need to conduct further USS-USS
communications in relation to the data provided in this message.
Sample of use cases:
1. PERIODIC_POSITION_REPORTS_START: need to know where to send positions.
2. OPERATION_ROGUE: need to know where to request op and pos data.
3. CONTINGENCY_PLAN_INITIATED: need to know where to request op data.
Since these use cases may require hitting different endpoints, only
the base url is required in the callback field. The receiver would
be responsible for determining which endpoint to use for follow up
data exchanges.
Note that "base URL" here implies the full path with protocol (only
HTTPS allowed) upto where trailing USS-API endpoints would be applied.
See example.
type: string
format: url
example: "https://superutm.uss/nuss/uss"GUD uses even less specification that this for URLs (just a string without format specifier), so I think we are fine.
Will close this one. If I misjudged or misunderstood, please continue conversation here.
Sprint4 UtmMessage .callback is now required. What is the USS Spec for validating inbound UtmMessage.callback? Must the USS validate message.callback for format/syntax and starts with 'https:'? or must the USS also validate that callback is reachable?
If also the latter, then another data exchange needs to happen (HEAD) before returning from servicing PUT UtmMessage. OTOH if the callback is not reachable then unknown future USS data exchanges will fail.
My suggestion is just check for RFC2396 syntax . (see b1nary.atr0phy https://stackoverflow.com/questions/1600291/validating-url-in-java)
Priya Venkatesan [5:48 PM] @irene - NASA it should be same as what grid uses