Payload format for SOME/IP transport should not be UNSPECIFIED

[sophokles73]

SOME/IP has no concept of payload encoding and/or content types. The SOME/IP Transport spec therefore advises to leave a UMessage's payload_format as UNDEFINED when mapping a SOME/IP message to a UMessage, assuming that the receiver will know how to interpret the data.

Using the UNSPECIFIED payload format for this purpose, however, seems inappropriate because uattributes.proto defines UPAYLOAD_FORMAT_PROTOBUF_WRAPPED_IN_ANY to be assumed as the payload format if UNSPECIFIED (not set). This means that any uE that is not aware of the fact that the message originates from a SOME/IP service, will try to process the message payload as a protobuf wrapped in an Any.

[PLeVasseur]

Hey Kai. So is the proposal to leave the payload_format empty instead to truly say "we have no idea"?

Or to modify the meaning of UPAYLOAD_FORMAT_UNSPECIFIED to truly mean "we have no idea"?

IMHO having UPAYLOAD_FORMAT_UNSPECIFIED mean "yeah... maybe it's UPAYLOAD_FORMAT_PROTOBUF_WRAPPED_IN_ANY actually?" seems a bit unintuitive. So I'd vote for the latter idea.

What are your thoughts?

[sophokles73]

The reason for defining UPAYLOAD_FORMAT_UNSPECIFIED as meaning UPAYLOAD_FORMAT_PROTOBUF_WRAPPED_IN_ANY was that we wanted to be able to simply omit the attribute in the majority of messages, because the most prevalent payload format is expected to be UPAYLOAD_FORMAT_PROTOBUF_WRAPPED_IN_ANY. FMPOV this still makes sense.

When we want to express Sender/Receiver need to know the format, we should therefore probably use some dedicated format identifier. IMHO UPAYLOAD_FORMAT_RAW would probably be the best fit, it resembles the standard Mime Type application/octet-stream which is used to indicate that it is some kind of (unknown) binary data.

WDYT?

[PLeVasseur]

Hmm. I suppose I don't know enough about MIME types, but a quick search seems to indicate that's a reasonable choice:

application/octet-stream is the default value for all other cases. An unknown file type should use this type. Browsers are particularly careful when manipulating these files to protect users from software vulnerabilities and possible dangerous behavior.

More-or-less saying "I dunno :shrug:"

Seems reasonable. Anyone have any other thoughts?

[gregmedd]

I agree that "unspecified" should mean just that - it was not specified and is left up to sender and receiver to know what to do. Maybe that means protobuf wrapped in any, but maybe it doesn't.

Alternatively, we could define a new type to represent unspecified SOME/IP payloads and always set that for messages received over the SOME/IP transport.

[stevenhartley]

Hi @sophokles73 agree that we sould use UNSPECIFIED to mean just that and we move the ambiguity/confusion around defaults when not specified. If it is not specified, we do nothing at the L1 & L2 layer and in our language libraries.