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:  
[mailto:] 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 
      <> 
  

    To: 
    Business Document Exchange TC List 
      <> 
  

    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