|ID||Submitter name||Submitter e-mail||Paragraph||Type||Comment||Proposed change||TICC CMB Notes and Decision|
|1||Gait Boxmanemail@example.com||4.2||added requirement not needed and not wanted||In 4.2, the port is limited to 443 only, which causes trouble for systems that have the AS4 system in parallel to e.g. a web server running on https as well, or running other webservices that occupy the same port. This limitation is not needed as clients can connect to any port that is open for access, whilst addressing through the SMP allows for alternative ports, just like with AS2. If there are implementations that fail to support alternative ports in the URL, they fail to comply with the https scheme, and should be repaired, rather than adding an unnecessary burden on the receiving service that then needs to separate https handling from the AS4 access point software in order to support mutliple serivces and software packages listening to the same ip:port whilst acting on different url paths.||Remove the limitation to port 443, allow https scheme https://hostname:portnr/path as per https URL scheme.||The limitiation to port 443 is removed. But avoid that all ports need to be open for outgoing traffic, it was decided to limit the port to be 443 or in the range 44300 (incklusive) to 44399 (inclusive) so that a) outgoing ports can be limited and b) non-standard ports can be used|
|2||Martin Forsbergfirstname.lastname@example.org||2||ge||I read the changelog to be the changes compared to version 1 of PEPPOL AS4 profile. But that seems not to be the case.||When publishing this as an approved spec, then take out the changelog or list the changes compared to the first version.||TICC CMB requests a ChangeLog from PEPPOL AS4 profile V1 to PEPPOL AS4 profile V2. And please remove the heading "Version 0.9.2"|
|3||Martin Forsbergemail@example.com||4.2||ge||Transport level security is required and it is specified how. In the v1 of the profile, TLS was not used but only message encryption. We agree with the decision to add TLS, but the profile should make it more clear that also message encryption is required. As it is now, it can be deduced by the P-mode setting in table 5 (4.7). ||The specification would benefit from introducing/describing the fact thattwo (three with signatures) security mechanisms are deployd.||It is mentioned in chapter 1, last sentence. It needs to be part of the new ChangeLog.|
Please add a sentence to chapter 4.7: "AS4 message level encryption MUST be used even though TLS is used."
|4||Martin Forsbergfirstname.lastname@example.org||4.4||ge||It says that "If a MSH is able to execute custom validations of the payload of a User Message" then a check can be done on the addressee. But both the service identifier (Action and Service) and finalRecipient are part of the "ebXML User Message" section and there is no need to actually validate the payload to see if the finalRecipient is known.|
Or does custom validation also mean that the accesspoint checks that these values corresponds/match (that is, the FinalRecipient=SBDH/ReceiverParty=Invoice|Order.../../EndpointID).
|If a MSH is able to validate the SBDH payload inside the AS4 User Message during the ebMS message processing, it is RECOMMENDED that the Access Point includes the check on the addressee.|
|5||Martin Forsbergemail@example.com||4.5||ge||Sweden is in a parallel to PEPPOL also implementing eDelivery for other domains. The PEPPOL Profile seems to fit our need to a very high degree and only a few configurations would need to be changed. One thing that would be helpful would be if the PMode.Initiator.Role and Responder. Role would be assigned more generic identifiers that can be used also outside of PEPPOL. Such as urn:eu:ec:cefxyz:edelivery_ap:sender/receiver. That way only the PartyId.type would need to be adapted.||Lets ask Martin for details what the motivation is and why SBDH is not an option|
|6||Martin Forsbergfirstname.lastname@example.org||4.6||ge||"When sending the business document the Access Point MUST set PMode.BusinessInfo.Service to the PEPPOL process identifier as specified in the PEPPOL BIS."|
When sending the business document the Access Point MUST set PMode.BusinessInfo.Service to the PEPPOL process identifier as specified for the business document.
Rationale: No only PEPPOL BISes are exchanged.
Same comment for Service.Type and Action
|Agreed to replace "PEPPOL BIS" with "business documents".|
|7||Martin Forsbergemail@example.com||4.7||ge||Describe in clear text that payload encryption is mandatory.||See ID 3|
|8||Martin Forsbergfirstname.lastname@example.org||4.1||ge||Question: when using payload encryption and compression in combination. Is the compressed content encrypted? Or is the encrypted content compressed? (should have significant effect on the compression efficiency.)||First compress, than encrypt, see |
Add a note in chapter 4.10 that compression comes before signing and encryption
|9||Davide Ciannamea IT-Abteilüng|
Enercom Swiss Finance SA
|email@example.com||4.1||ed||In reference to the following sentence: "Receiving access points MUST configure TLS on port 443" we proposed following change||"Receiving access point MUST configure TLS v1.2 on port 443 with configuration https to be configured in your access point".||Chapter 4.2: TLS v1.2 MUST be supported. Older versions (SSL v2, SSL v3, TLS 1.0 and TLS 1.1) MUST NOT be used. Versions newer than TLS v1.2 might be used upon mutual agreement via the TLS handshake.|
|10||Davide Ciannamea IT-Abteilüng|
Enercom Swiss Finance SA
|firstname.lastname@example.org||4.1||ed||In reference to the following sentence: "Sending access points need only to allow outbound transmissions using port 443" we proposed following change||"Sending access point MUST only to allow outbound transmissions using port 443 with the specific configuration https to be configured in your access point".||See ID 9|
|11||Davide Ciannamea IT-Abteilüng|
Enercom Swiss Finance SA
|email@example.com||4.4||ed||In reference to the following sentence: "The errorCode attribute of the generated Error MUST be set to EBMS:0004 (Other error) and its severity attribute MUST be set to failure." we proposed the following change, being a problem of communication to the destination access point.||"The errorCode attribute of the generated Error MUST be set to EBMS:0005 (ConnectionFailure) and its severity attribute MUST be set to failure".||Rejected. 0004 is correct.||0003: Although the message document is well formed and schema valid, some element/attribute value is inconsistent either with the content of other element/attribute, or with the processing mode of the MSH, or with the normative requirements of the ebMS specification.|
0005: The MSH is experiencing temporary or permanent failure in trying to open a transport connection with a remote MSH.
|12||Davide Ciannamea IT-Abteilüng|
Enercom Swiss Finance SA
|firstname.lastname@example.org||6.2||ob||In the following reference "Note that an Access Point MAY use a "generic" P-Mode to receive the registered business documents" we can hypothesize that the dynamic discovery of an Access Point could be indicated in this sentence because the dinamic discovery uses a generic P-mode configured in the access point.||-||Split chapter 6.2 into 2 pieces:|
a) SMP transport profile identifier
Stating only the transportProfileIdentifier (there is a typo in the current version)
b) AS4 and dynamic discovery
Outline that new P-Modes may need to be created per document exchange and outline what SMP response values fit where in a PMode. Also a note that this feature is non-standard AS4 might be worthwhile.
|13||Davide Ciannamea IT-Abteilüng|
Enercom Swiss Finance SA
|email@example.com||6.2||ed||We proposed the following addition to the end of paragraph 6.2||Receiver Access point records the Sender Access Point metadata in SMP and configures its PModes to be able to accept messages from trusted senders that are not previously configured in the PMode.||See ID 12|
|firstname.lastname@example.org||5||inconsistancy||PMode.Initiator.Role and PMode.Responder.Role have a different fixed value then described in chapter 4.5 urn:fdc:peppol.eu:2017:roles:ap:as4 vs urn:fdc:peppol.eu:2017:roles:ap:sender and urn:fdc:peppol.eu:2017:roles:ap:receiver||Update chapter 5 to make it in line with chapter 4.5||Align chapter 4.5 with Table 7 - the inconsistencies need to be resolved|
|15||Philip Helgeremail@example.com||4.9||according to the CEF profile the type attribute of the message properties “originalSender” and “finalRecipient” must be used. But please note that there is an issue with this attribute in the ebMS specification as it is not included in the XSD defining the ebMS header and therefore AS4 implementations executing schema validation of the header cannot handle this attribute (see also issue #2 in the OASIS ebMS TC’s issue tracker). In e-SENS and in CEF conformance testing this attribute isn't used, so it’s unclear whether it will be interoperable!||Issue: https://issues.oasis-open.org/projects/EBXMLMSG/issues/EBXMLMSG-2|
Include in the discussion with Martin Forsberg on ID 5; suggestion to remove the attribute "type" under the precondition that it is otherwise possible to clearly identifiy that the role is "PEPPOL AccessPoint"
|16||Philip Helgerfirstname.lastname@example.org||4.9||Also related to these properties is that in the CEF profile it is stated that "The consumer SHOULD validate that, for any message delivered to it, the values of the AS4 Four Corner message properties match the values of the corresponding SBDH values.”. The consumer system is the back-end system, so this mixes responsibilities! It makes the integration between AS4 gateway and back-end more complex as these properties need to be exchanged. Additionally it is unclear what the consumer should do in case the value do not match. This results in unpredictable behaviour.|
|17||Philip Helgeremail@example.com||ge||There is no normative statement on the value to use for ConversationId. To prevent interoperability issues I would recommend to specify to use the default value (as it was in the first profile)||Please add the sentence from PEPPOL AS4 profile V1:|
As the eb:ConversationId element is required it MUST always have a value. If no value is included in the submission of the business document to the Access Point, the Access Point MUST set the value of eb:ConversationId to “1” as specified in section 4.3 of [ebMS3CORE].
|18||Philip Helgerfirstname.lastname@example.org||ge||That the P-Modes should be dynamically created based on the meta-data retrieved from the SMP is completely missing from the document.||See ID 12|
|19||Philip Helgeremail@example.com||ge||Please remove me from the Contributors list||Approved|