[Moims-sc] MAL HTTP XML update - revision D

[Dominik Marszk]

Dear all,

The agreed edits to HTTP binding are all finally applied. Apologies it took so long.
Attached you will find:

  *   DOCX with changes redlined since previous release of the standard
  *   PDF without redlines

Both are also uploaded to CCSDS sharepoint:
CCSDS Mission Operations and Information Management Services Area (MOIMS) - Documents - 524.3-B-2 - All Documents<https://spacecomm.sharepoint.com/sites/MOIMS/Shared%20Documents/Forms/AllItems.aspx?id=%2Fsites%2FMOIMS%2FShared%20Documents%2FMOIMS%2DSMandC%2FDraft%20Documents%2FCCSDS%20524%2E3%2DB%20%2D%20MO%20MAL%20Binding%20to%20HTTP%20Transport%20and%20XML%20Encoding%2F524%2E3%2DB%2D2&viewpath=%2Fsites%2FMOIMS%2FShared%20Documents%2FForms%2FAllItems%2Easpx>

Most notable changes, together with some detailed notes, open points and caveats:

  *   On headers:
     *   Header mapping & encoding is now a part of the Transport spec, and entirely detachable from the XML encoding.
     *   Applied a lean approach to string encoding (percent-encoding) and Supplements in the header
     *   Explicit requirements for an out-of-band mapping of the header to HTTP destination URL (with example that the simplest mapping is just `URL:=To`)
  *   On XSD:
     *   XSD schema rules have been harmonised and simplified to result with a minimal and consistent XSD
     *   Namespaces and assumption about them are now explained in 4.2.1
     *   Note that double-wrapping each Attribute value (first into type, then into object) is unfortunately a necessity to maintain polymorphism and XSD compliance. If anybody has a better idea how to represent it in XSD-compliant manner I'm all ears!
     *   MAL Message Body XSD type is *not* specialised in any way in the schema, except for simply saying that it must contain 0 or more any elements. This is fairly nonstandard and I do not love it, as there is nothing to bind the element name to its type, meaning that all top-level elements in MAL operation Body cannot be XSD-validated nor XSD-generated.
        *   There is an option and a place to define dedicated XSD types representing different Body types for all stages of all operations, making Body structures fully represented in XSD. Do we want to do that?
     *   Annex B now says - "Mission Operations Services XML registry of SANA is populated with the XML Schema Definition sheets representing the XML encoding of all published normative MO Areas." - giving us a background to upload all XSDs to SANA
  *   Examples:
     *   I opted to keep only Subscription example, but it should now be matching the rest of the document
     *   Putting more examples in-line with the types feels a bit messy. Perhaps we could make it an extra Annex, and throw more example encoded bodies in there, perhaps building on top of https://github.com/esa/mo-services-java/blob/master/tooling/basic-demo/src/main/resources/MALDemo.xml ?
  *   Editorial:
     *   All normative references (in 1.9) were updated - all old HTTP RFCs replaced with latest standards from 2022, but note:
        *   I'm not 100% sure if 'ISOC' is the right attribution (marked in yellow) - for maximum clarity I referenced both RFC and STD codes where available
     *   In Annex D we still have a bunch of very old informative references (spanning 2006-2017) - I did not touch any of these and they might be all to be updated.

I am working on applying the changes on top of V14 ESA stack. I am creating a python-based XSD schema generation tool to be able to create XSDs for SANA.
If you have any comments, let me know. For the Fall meetings I will have a few slides summarising the changes and the prototyping, as well as answers to any comments you might have.

Best regards,
Dominik

ESA - European Space Agency

Dominik Marszk
System and Applications Engineer
Ground Segment Systems and Cybersecurity Engineering Section (OPS-GAE)

ESOC - European Space Operations Centre
Robert-Bosch-Strasse 5, 64293 Darmstadt, Germany
dominik.marszk at esa.int<mailto:dominik.marszk at esa.int> | www.esa.int<http://www.esa.int/>
T +49 6151 902219

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20250905/f0e17b9a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 524x3b2_ MAL_HTTP_XML_revD_no_redline.pdf
Type: application/pdf
Size: 1211330 bytes
Desc: 524x3b2_ MAL_HTTP_XML_revD_no_redline.pdf
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20250905/f0e17b9a/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 524x3b2_ MAL_HTTP_XML_revD_redlined_since_2018.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 651484 bytes
Desc: 524x3b2_ MAL_HTTP_XML_revD_redlined_since_2018.docx
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20250905/f0e17b9a/attachment-0001.docx>