MEETING MINUTES OF BDXR TC MEETING 14 OCTOBER 2015
ATTENDANCE
Jens Aabol
Kenneth Bengtsson (chair)
Erlend Klakegg Bergheim
Regrets received in advance:
CACHING OF SMP RECORDS AND GENERAL SCALABILITY OF BDXL+SMP
Erlend and Sander brought up that the subject of caching of SMP records is being debated in the PEPPOL community, where users of SMP are experiencing increasingly heavy traffic. It was agreed that the TC shall issue an official TC Note with a
recommendation/best practice for caching SMP records in a BDX network.
It was agreed to recommend that: SMP caching be based on standard HTTP headers for when a record was last modified. It is up to the SMP publishing service to decide whether to display HTTP last modified header or not. In case an SMP client wants
to implement caching he must the HTTP last modified header to decide whether to cache or not. In case that the last modified header is not present in the response from the SMP publisher then caching shall not take place.
Erlend volunteered to commence the work with the TC Note and edit the product with support from the group.
DG DIGIT has pointed out an inconsistency in the SMP 1.0 spec in that section 3.2 states that "a service implementing the REST profile MUST NOT use TLS (Transport Layer Security) or SSL (Secure Sockets Layer)", which is then later contradicted
in section 3.6.1 stating that "at the transport level a Service Metadata Publishing service may either be secured or unsecured depending on the specific requirements and policies of a business document exchange infrastructure".
The statement in section 3.2 is an erroneous leftover from the original PEPPOL specification. PEPPOL does not allow the use of HTTPS for SMP services because of the architecture of the SML location service used in PEPPOL. In SML, all SMP servers
in a community are called using a DNS name under a common domain name (i.e. "[participant].[scheme].[community domain name]"). Consequently all SMP servers in an SML network respond to the same domain name, and SSL certificates issued to individual domain
names of SMP providers would cause validation failures at the transport level.
BDXR solved this problem in our BDXL specification ( http://docs.oasis-open.org/bdxr/BDX-Location/v1.0/BDX-Location-v1.0.html), which is an update for
the SML specification. In BDXL the DNS name of the SMP server is resolved using pointers in the DNS record instead of using hardcoded hostnames, and therefore SMP servers do not have to be called using the same domain name. Therefore there are no problems
with using HTTPS with SMP services, as long as BDXL and not SML is used for SMP service discovery.
All present members at today's call agreed that section 3.6.1 of the SMP 1.0 Committee Specification prevails over section 3.2, and that HTTPS is allowed with SMP. It was furthermore agreed that the correct procedure is to remove the erroneous
statement from the SMP specification, and it was agreed that such change does not substantially modify the specification or the meaning of the specification.
TC NOTE ON THE USE OF SMP EXTENSIONS
Kenneth has requested a starter document for the TC Note on use of SMP Extensions discussed at the last TC meeting. It is expected that a first draft of the TC Note is ready for our next meeting, October 28. Sven has been in contact with the user
submitting the question (OpenNCP) and informed them of our discussion and conclusion.
UPDATE ON BDXL AND SMP STATEMENTS OF USE
The TC has been contacted by a group developing a document standard for presenting strategic plans in a structured format, StratML ( http://xml.fido.gov/stratml/index.htm). StratML has
expressed interest in BDXRs products and in how these can facilitate communicating StratML documents, and in exploring a formal collaboration for promoting structured and secure business communication. It was agreed to allow Kenneth to liaison with StratML
on BDXR's behalf to further pursue a possible collaboration.
OpenPEPPOL has offered to let BDXR take over the LinkedIn group that was originally established under the PEPPOL project to facilitate debate for PEPPOL's transport infrastructure (available here: https://www.linkedin.com/grps/OpenPEPPOL-eDelivery-Forum-4092797/about).
Since the group's specific subject is the PEPPOL transport infrastructure, who's specifications are now maintained and further developed by BDXR, it is assumed that its members all have an interest in BDXR. The group currently has just over 400 members. It
was agreed to accept the gesture from OpenPEPPOL. Kenneth to communicate the decision to OpenPEPPOL, and to communicate the change to the LinkedIn group's members.
October 28 2015, regular conference call
November 11 2015, regular conference call
November 25 2015, regular conference call
|