bdxr — archive

[Kenneth Bengtsson]

Minutes of Atlantic BDXR TC call 05 June 2019 15:00UTC http://www.timeanddate.com/worldclock/fixedtime.html?iso=2019-06-05T15:00:00 Atlantic: 10:00MSP/10:00Lima/11:00Ottawa/15:00UTC/17:00Europe Participation Jens Aabol Todd Albers Kenneth Bengtsson (chair) Ger Clancy Sander Fieten Philip Helger Matt Vickers Pacific participation: Kenneth Bengtsson (chair) Erlend Klakegg Bergheim Levine Naidoo Standing items Review of Pacific call minutes https://lists.oasis-open.org/archives/bdxr/201906/msg00002.html Review of Atlantic call minutes https://lists.oasis-open.org/archives/bdxr/201905/msg00016.html Membership status review https://www.oasis-open.org/policies-guidelines/tc-process#membership Voting status is determined by the following: existing voting members must not miss two consecutive meetings to maintain voting status non-voting members must attend two consecutive meetings to obtain voting status members formally on leave by prior request must not attend and their voting status is not impacted Current BDXR TC voting member list (alphabetical): - Jens Aabol - Todd Albers - Kenneth Bengtsson - Erlend Klakegg Bergheim - Ger Clancy - Sander Fieten - Ken Holman - Levine Naidoo - Matt Vickers SMP 2.0 SMP 2.0 Committee Specification 01 approved and published: https://docs.oasis-open.org/bdxr/bdx-smp/v2.0/bdx-smp-v2.0.html Comments received from Philip: - https://lists.oasis-open.org/archives/bdxr-comment/201905/msg00002.html o Why did you change the data type of "ActivationDate" and "ExpirationDate" from "xs:dateTime" to "xs:date"? Changed from dateTime to date based on comments from the EC and PEPPOL implementors, see for example: https://lists.oasis-open.org/archives/bdxr/201602/msg00006.html Agreed to clarify the unbounded relation between the activation and expiration date of certificates in SMP and the validity of certificates themselves, either in Committee Note or on the mailing list. - https://lists.oasis-open.org/archives/bdxr-comment/201905/msg00003.html o Add an additional "<xs:choice>" in the XSD around "Endpoint" and Redirect" elements: Agreed to postpone discussion to include Ken o the terminology "SHOULD" in "ActivationDate" and "ExpirationDate" is causing problems in production, because clients are not enforced to reject expired elements Agreed that there may exist valid reasons in particular circumstances for an implementor or implementing community to ignore the service activation and/or expiration date, however such decisions should be made by the implementing community and not by the TC. o The description of elements "ActivationDate" and "ExpirationDate" refers to "ExpirationData" instead of "ExpirationDate" This was fixed in the published Committee Specification o The documentation states "0..1" "Certificate" elements, but the XSD uses "0..unbounded" Agreed that the cardinality stated in the prose specification (0..1) is the correct o Element "ContentBinaryObject" has an attribute "mimeCode" - is there a codelist of registered MIME code values and their meaning that MUST be supported? Agreed that the TC does not constrain the usage and types of certificates, nor the any mime codes associated with the use of a specific certificate type. o Appendix B - editorial - the XML code has one closing angle bracket too much (the very last char) This was fixed in the published Committee Specification o Another question on XSD: what is the motivation on having the 2 basic types "ParticipantIDType" and "IDType" that have the same semantics? Can't the types be merged (without changing the element names)? Agreed to postpone discussion to include Ken Exchange Header Envelope (XHE) Draft Migration and Implementation Guide has been developed and reviewed by the project group: https://www.oasis-open.org/committees/document.php?document_id=65417&wg_abbrev=bdxr Committee Note to be voted on at next meeting. Need to update conformance statement of the specification to allow Payload elements when used as a header. BDXL administration interface Proposal from Erlend: https://lists.oasis-open.org/archives/bdxr/201905/msg00015.html Kenneth to request starter document for a Committee Specification. To be discussed at the next meeting: Are we proposing only one binding or do we allow multiple bindings as we do in SMP? The proposed model suggests that only a REST binding is considered. TC conference call schedule Call schedule 2019-06-19 - Pacific: 20:00MSP/20:00Lima/21:00Ottawa/01:00UTC/11:00Sydney - Atlantic: 10:00MSP/10:00Lima/11:00Ottawa/15:00UTC/17:00Europe 2019-07-03 - Pacific: 20:00MSP/20:00Lima/21:00Ottawa/01:00UTC/11:00Sydney - Atlantic: 10:00MSP/10:00Lima/11:00Ottawa/15:00UTC/17:00Europe 2019-07-17 - Pacific: 20:00MSP/20:00Lima/21:00Ottawa/01:00UTC/11:00Sydney - Atlantic: 10:00MSP/10:00Lima/11:00Ottawa/15:00UTC/17:00Europe 2019-07-31 - Pacific: 20:00MSP/20:00Lima/21:00Ottawa/01:00UTC/11:00Sydney - Atlantic: 10:00MSP/10:00Lima/11:00Ottawa/15:00UTC/17:00Europe 2019-08-14 - Pacific: 20:00MSP/20:00Lima/21:00Ottawa/01:00UTC/11:00Sydney - Atlantic: 10:00MSP/10:00Lima/11:00Ottawa/15:00UTC/17:00Europe 2019-08-28 - Pacific: 20:00MSP/20:00Lima/21:00Ottawa/01:00UTC/11:00Sydney - Atlantic: 10:00MSP/10:00Lima/11:00Ottawa/15:00UTC/17:00Europe Other business Nothing