We’ve jumped into discussion of some important technical details here, but missed what I thought was Pim’s most important, first point. And that was, that the pre-existing PEPPOL specifications were taken and assumed as the baseline and trajectory for the TC. There appears to be a relatively high bar set for justifying any proposals that vary from this – one which the PEPPOL stack has not been required to meet. Looking back at the TC Document repository, I see twenty or so PEPPOL-originated specification documents, but not a single one setting out the requirements that led to those specifications. Without the TC seeing and discussing those requirements, it’s hard to have a dispassionate discussion.
It seems so obvious as to be hardly worth stating that successful Internet scale standards tend to be those that define the simplest possible approach to meeting the core requirements in a particular domain of most users. It follows that if different user communities have different requirements, the “simplest possible approach” nonetheless does need to support a superset of those different communities’ requirements. And if global interoperability is a requirement, this is even more true. Even if this is all obvious, it has implications for how we conduct BDX discussions, and so is perhaps worth some explicit consideration.
So if we have use cases or requirements being raised within BDX that differ from the PEPPOL specs and their (unstated?) requirements, it seems unhelpful to just refer back to the wisdom of the PEPPOL designers. Speaking for myself, but perhaps others too, unless these requirements can be addressed in an open and even-handed way, BDX will simply rule itself out as the venue for defining standards that have any realistic chance of adoption at Internet scale.
To go one level deeper, on some of the different technical points raised, it seems to me we may be conflating STANDARDS specifications, and OPERATIONAL considerations about how those standards are implemented in different contexts. On the use of DNS standards for example: even if a DNS-based registry protocol were agreed for BDX applications, to me it does not follow at all that it would be managed through the same (sometimes slow and clunky) operational processes that manage endpoint DNS infrastructure today.
Similarly, regarding the social network/connect models: any standard should allow operational flexibility to handle this at different levels. On the one hand, it should not require duplication of agreement content that is handled by other systems out of band. But conversely (and this is a primary concern I have), the machine-to-machine registry and handshake model should allow for the possibility of fully automated setup, without requiring separate (manual) processes for some of the required steps.
Best regards,
Roger
From: bdx@lists.oasis-open.org [mailto:bdx@lists.oasis-open.org] On Behalf Of Pim van der Eijk
Sent: Wednesday, November 23, 2011 9:11 AM
To: 'Business Document Exchange TC List'
Subject: RE: [bdx] BDX address recipe outline.
This discussion was supposed to be about SML/SMP (registry, routing, capabilities) not about transport, but let's do the ebMS comments first: in ebMS 3.0, the reference to the agreement is no longer a required message header element. An explicit agreement reference is sometimes useful (that is why it is still an optional header element) but not always. Not requiring it in the header is more flexible and allows for implementations to have "default" agreements, or to derive the relevant agreement information from other information, or some other way.
Some kind of default or on-the-fly generated agreement would be needed for the "connect" feature, unless it were mediated by some trusted third party match maker. I was using "agreement" in a loose sense.
SML/SMP are about routing and about expressing capabilities. My point was that there are areas where you want to be able to support receiving some types of documents from particular partners but not from others or don't want to advertize your capability to support particular services to every partner and non-partner in the same way. Not everyone wants his name and address to be in the phone book, but you do want the telco to route calls to your number. It is not uncommon for B2B gateways to act as a kind of ERP firewalls, in which case they are used to prevent delivery of documents. Just as some people set their phone to screen calls using white lists or black lists. Perhaps this is not as important in some areas as it is in others, but this doesn't mean the architecture should be hardwired to support just one set of choices.
Pim
From: Martin Forsberg [mailto:martin.forsberg@ecru.se]
Sent: 23 November 2011 12:58
To: Pim van der Eijk; 'Mike Edwards'; 'Moberg Dale'
Cc: 'Business Document Exchange TC List'
Subject: SV: [bdx] BDX address recipe outline.
Hi Pim,
Regarding the social network/connect-analogy: We have been using ebms for quite some time in Sweden and one of the biggest issues is that most ebms-implementations require an agreement before-hand. This agreement (CPA) is also referred to in the ebms-header. We have tried to build around this by defining agreement-id schemes that can be deduced by other information elements (like service/action). So for use, it really doesn’t give much value.
All implementations that I come in contact with have a “connect-feature” as part of their e-business software or e-invoice software where they keep track of their business partners. To also maintain this on a messaging-level (often outsourced to a service provider) is creating a lot of extra work.
/Martin
Från: bdx@lists.oasis-open.org [mailto:bdx@lists.oasis-open.org] För Pim van der Eijk
Skickat: den 23 november 2011 12:04
Till: 'Mike Edwards'; 'Moberg Dale'
Kopia: 'Business Document Exchange TC List'
Ämne: RE: [bdx] BDX address recipe outline.
Today I can only attend the first part of the meeting, so here is some written input in case we don't get to discuss this.
First of all, I think it is not just the people asking questions about, or proposing alternatives to, the various specifications submitted to this TC who should provide use cases and requirements. I would even more like to see some more discussion of (and justification by their authors for) the requirements and use cases that underly SML/SMP and related specifications themselves, if memory serves the authors of those specifications correctly. This will help us all to understand how general and reusable these specifications are, and find and fix any aspects that perhaps are too hard-wired to the specific PEPPOL context to be of general use.
To elaborate a bit: SML/SMP are not the first or only attempts at specifications for e-business registry or capability _expression_ functionality, and there are both strong similarities and differences compared to these earlier approaches. So as a start, an overview that explains how the design of SML/SMP relates to (and why it differs from) them would be useful. Some of these differences are interesting, but not all of them strike me as improvements. I've mentioned before the absence of the equivalents of ebXML CPP "CanSend"s in SMP. Another is the absence of a concept of an agreement or service versioning. Without similar concepts, in BDX, if I publish that I can receive a particular version of a UBL invoice, how do I express that I only want that option to be used by a specific limited set of trading partners? How can I express that I only support a deprecated version for some established partners, or for partners that sent me a a document of some related type before, but want others to only use the newer one? How can I express that any messages from me will be not be sent from any Access Point, but only from a particular named Access Point that I trust using specific credentials? Earlier established protocols like CPA support this very well and are used in production today, I don't see how SML/SMP/BDX handles this.
As an analogy: in social networking, someone first has to connect to you before he/she can send you messages or flood you with their network updates. You have an option to not accept a connection invitation. You even have an option to no longer accept invitations at all (if you've set up your closed community). This seems to be something that a register-based collaboration architecture should support if it wants to be a general solution. The majority of e-government networks are closed or semi-closed, e-procurement networks are the exception rather than the rule. The OASIS EnergyInterop TC has a party registration service concept, which could be combined with a limited capability matching/intersection functionality. And no, I'm not buying that this functionality would be too complex. SSL has long had a handshake mechanism and is one of the most widely used Internet protocols. There are even handshakes in Web Services protocols such as WS-ReliableMessaging. Capability intersection has been implemented in CPPA and other specifications, all of which could be used or profiled further if desired.
On the particular subject of DNS, I read Dale's email (as far as I understand it) as stating that it can do a lot more than SML/SMP use it for. So for architectural coherence it might make sense to use it more generally in the BDX architecture. I would rather raise a different issue: a major drawback of a system that depends on DNS updates is administration overhead, because DNS management is often outsourced to hosting providers or telcos. You cannot typically update DNS records from a business application directly, but have to go through some (often horribly slow) service management processes, at best partly automated. Today, in some ebMS 2.0 environments I've worked in, connecting a new partner means writing a CPA, which is usually simple and done in a few minutes, then waiting a week or even longer for all the firewall changes, NAT rules etc. to be implemented. I'm sure they're not looking forward to adding DNS update dependencies in this mix ...
So I'm wondering what problem DNS is a problem for. I know it offers scalability, but is this level of scalability even needed for a business registry? Previous e-business registry standards failed to take off, but lack of scalability does not seem to rank highly on the list of reasons why. Similar business registries, such as the GS1 GEPIR, or the various national systems of chambres of commerce, seem to not have found the need for it, yet they process (I have some hands-on experience with this) huge amounts of queries using regular HTTP-based exchanges.
Pim
From: bdx@lists.oasis-open.org [mailto:bdx@lists.oasis-open.org] On Behalf Of Mike Edwards
Sent: 31 October 2011 17:07
To: Moberg Dale
Cc: Business Document Exchange TC List
Subject: Re: [bdx] BDX address recipe outline.
Dale,
I don't mean to be rude, but your post sounds like a solution looking for a problem.
Just because DNS permits the approach you describe, it isn't clear to me what real usecases are dealt with using
this sort of technique. Perhaps you could cover the major usecases that you see addressed by such a solution?
As far as the cryptographic hash is concerned, if my memory serves me correctly, it was introduced somewhat unwillingly
into the PEPPOL model once we realized that there were types of participant ID that could not be accommodated in
standard address strings used for DNS lookups. The hash technique chosen has the advantage of always generating
a string that works for the lookup while at the same time being available ubiquitously and so easily accessible to any
software looking to implement the PEPPOL protocols. The masking of the ID for commercial purposes was not part of
the considerations as far as I recall.
Yours, Mike
Dr Mike Edwards | Mail Point 137, Hursley Park |
| |
STSM | Winchester, Hants SO21 2JN | ||
SCA, Cloud Computing & Services Standards | United Kingdom | ||
Co-Chair OASIS SCA Assembly TC | | ||
Chair UK ISO SC38 mirror committee (Cloud & SOA) | | ||
IBM Software Group | | ||
Phone: | +44-1962 818014 | | |
Mobile: | +44-7802-467431 (274097) | | |
e-mail: | | ||
| |||
| |||
From: | Moberg Dale <dmoberg@axway.com> |
To: | Business Document Exchange TC List <bdx@lists.oasis-open.org> |
Date: | 25/10/2011 18:51 |
Subject: | [bdx] BDX address recipe outline. |
Sent by: |
In this message, a way to use IETF DNS functionality for the BDX address resolution is sketched. The resolution using a canonical concatenated string of bdx metadata that has been made opaque (in whole or part) by using a cryptographic hash. Apparently this masking has been required to meet some commercial concerns about not disclosing what organizations use which providers).
The main point here is to show that BDX address lookup requirements are met by using a known registry (DNS) with known internet scalability and manageability, using already existing approved standards.
By analogy with ENUM, (see information box below for an introduction to ENUM from voip-info.org), we can therefore concatenate BDX service metadata identifiers to a string in a canonical way, use sha-256 to produce a resource identifier, introduce a DNS NAPTR record for that identifier in the “peppol.org” domain or whatever , do a DNS query on the resulting value, and resolve in a standardized way (indicated by the “A” flag of the NAPTR record) to A, AAAA or A6 address records.
(For extra spice, add DNSSEC to prevent cache poisoning at the “peppol.org” domain. Use DANE for DNS based PKI if desired for TLS. Many variations are possible for the NAPTR string on concatenation order, separators, hashing procedures to meet visibility or nondisclosure concerns. Another variation would insert a “S” flag in the NAPTR RR, and then look up SRV records for a domain name key, from which address records would be obtained. This additional step would allow multiple BDX servers to be advertised for a provider, e.g.)
IETF has evolved DNS to support many use cases beyond simple FQDN to Inet address lookups. Isn’t it preferable to actually use DNS, its query system, and its zone update management procedures instead of creating a hybrid Web Service and DNS mashup for a use case that is already easily handled by a simple profile of current specifications?
From http://www.voip-info.org/wiki/view/ENUM
You can dial a telephone number and reach a SIP, H.323 or any other Internet Telephony user. This all happens in the background; you do need to do anything special while calling someone.
A server with ENUM support will lookup a dialed telephone number in the ENUM tree of the DNS to see if there's alternate ways to set up the call instead of just calling out on the PSTN telephone line. ENUM may contain a reference to a SIP URI, a telephone number to dial, a web page or an e-mail address.
Enum uses DNS NAPTR resource records.
DNS NAPTR resource records are documented in RFC 2915: This document describes a Domain Name System (DNS) resource record which specifies a regular _expression_ based rewrite rule that, when applied to an existing string, will produce a new domain label or Uniform Resource Identifier (URI). […] This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax. Reasons for doing this range from URN Resource Discovery Systems to moving out-of-date services to new domains.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU