Open 6a6d74 opened 3 months ago
The idea of x-
is to allow using unregistered names for particular usage.
So, for me using x-bufr and x-grib falls perfectly in this situation.
However, those are standard in quite a large community ans therefore should be registered.
I would therefore do:
When agreed, update the guide.
Also CAP is now marked application/xml. That should have its own as well. Now type is only way to know what type of data it is (from notification), so it should be as specific as possible, not just application/xml in this case. There is also problem in content property (of notification message), it does have encoding property but not type, so currently there is no way to know that inline content is.
When the TT-TDCF discussed this, they recommended the following approach:
Based on this @amilan17 , can WMO Sec. starts the procedure ?
There's variation in how WIS2 Nodes are declaring the mime type for data being shared on WIS2 (e.g., within the link object(s) of WIS2 Notification Messages) .
BUFR files might be given:
"type": "application/octet-stream"
or"type": "application/x-bufr"
.x-bufr
(andx-grib
) aren't officially registered mime types, so there's reluctance to use them.octet-stream
could be any kind of binary format, which isn't helpful for client applications!We need guidance on what mime type(s) to use.
Would also be good if BUFR and GRIB were properly registered.
I think we have 3 issues to resolve:
For reference: