[bdxr-comment] Re: Invitation to comment on Service Metadata Publishing

Dear OASIS BDXR team,

Please find below the comments from the CEF eDelivery:

CEF-01: PDF version has images with blurred / not readable labels.

Suggestion: update the following images so that they have readable labels in PDF.
- Fig 1: Participant lookup with Service Metadata
- Fig 3: SMP class diagram

CEF-02: Definition of the "4 corner network"

A network is a group of participants in a domain, and the topology describes how they are connected.
- If both end-nodes are connected directly, then the connection topology is 2 corner topology;
- if one node is connected directly and the other uses an intermediate node (also known as the Access Point), this is 3 corner topology.
- If both nodes are using the intermediate node, then this is 4 corner topology.
https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+AS4+-+1.14#eDeliveryAS4-1.14-FourCornerTopology

Technically, the intermediate node (AP) implements functions for reliability, security, non-repudiation of the message transfer. From a business point of view, the AP can be a service provider, general software solution provided by a third party, or custom implementation "extracted" from the backed application(s) .

Suggestion: Replace "4 corner network" with the "4 corner topology".

CEF-03: The SMP specification is bound only to a "4-corner network."

In the introduction chapter starts with sentence:
> This document describes the Service Metadata Publishing protocol (SMP) and its binding to a [REST] interface for Service Metadata Publication within a 4-corner network It defines the data model for the messages exchanged between a Service Metadata Publisher and a client application wishing to discover the endpoint information ....

But then in the same chapter is written:
> "A client application in this context can either be an end-user business application or a gateway in a 4-corner n

If the "end-user business application" tries to discover the receiver's URL/Certificate to send a message, then this is a 2 or 3 corner topology (see the CEF-02).

We also propose to remove "binding" the SMP specification only to 4-corner topology with purpose to enable various business use-cases.

Suggestion: Remove 4-corner network binding to allow to use OASIS SMP spec. also in other "corner topologies"
and describe in one chapter how SMPs specification is used in 4-corner topology.

CEF-04: Conflicting statement: "one and only one Service Metadata Publisher"

In the chapter "2.1.1 Introduction is written
> Each Participant is registered with one and only one Service Metadata Publisher.
and in chapter is written:https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+AS4+-+1.14#eDeliveryAS4-1.14-FourCornerTopology

2.1.3 Service Metadata Publisher Redirection is written:
However, there are cases where a Participant would want to use different Service Metadata Publishers...

We understand that Participant can register data in multiple Service Metadata Publishers, and then just one must be registered in BDXL implementation. And that one then points to different Service Metadata Publishers. Is this correct?

Suggestion: Remove the statement: "Each Participant is registered with one and only one Service Metadata Publisher." Or elaborate better on how Participants can use different Service Metadata Publishers to be consistent with "one and only one Service Metadata Publisher" statement.

CEF-05: Various names for one the same entity:
Sender, SMP client, or as Sender client

"SMP client entity" has different names for example :see the chapter: Service Metadata Publisher Redirection

where Sender is sometimes mentioned as Sender, SMP client, or as Sender client.
Different names for the same entity make it harder to understand the specification.

Suggestion: Use one name for the entity: for example "SMP client"

CEF-06: Proposal for adding new filed "Identifier" to the Endpoint (chapter: 4.3.6 The Endpoint class)

In 4-Corner topology using the AS4 profile, all corners must-have their own identifiers. For example in the PEPPOL network, for corners 2 and 3 (the Access Points ),
the AP certificate's CN value is also used as an AP identifier.

The attribute would enable to SMP client to register AP's Identifier along with his Certificate and URL.

Suggestion: Add new filed "Identifier" to the Endpoint (chapter: 4.3.6 The Endpoint class)

CEF-07: Allowed HTTP statuses

5. In chapter 5.2.1 General use of HTTP 1.x
is written:
HTTP GET operations MUST return the following HTTP status codes: 200, 404 and 5xx
but then in chapter 5.2.2 Caching of the HTTP response
where is referenced to
RFC7232 for Last-Modified and If-Modified-Since HTTP headers.
To implement the RFC7232, also http 304 should be allowed.

https://tools.ietf.org/html/rfc7232
An origin server that receives an If-Modified-Since header field
   SHOULD evaluate the condition prior to performing the method
   (Section 5). The origin server SHOULD NOT perform the requested
   method if the selected representation's last modification date is
   earlier than or equal to the date provided in the field-value;
   instead, the origin server SHOULD generate a 304 (Not Modified)
   response,

Suggestion: Add also HTTP status codes 304 to the list of allowed codes

Kind regards

Joze Rihtarsic

bdxr-comment message