Mike,
The NAPTR resource record is more flexible in allowing DNS “discovery queries” than CNAME resource records (which are usually used to provide aliases).
NAPTR records can also be used to discover URLs that can enable lookup of specific documents, such as ones profiling service offerings and QOS options. There
can be documents of different types, such as ws-policy, ebxml cpp, or others.
But I am trying to get people such as yourselves to state what are the BDX requirements and use cases for which standardization is being sought. It seems to
me that the BDX submissions are themselves presented as solutions to a great variety of concerns. But not all of these may be required as a bundle for all industries or regions.
I think that the 4-corner model (aka, SIP trapezoid or the APEX relaying mesh) is relevant in giving some structure to “cloud” computing solutions for b2b or
x2x data exchange.
However, I am not convinced that the current specifications isolate core “interconnect” issues nor pose discovery issues in clean generally applicable ways.
Converting the PEPPOL project documents to generally applicable modules for business document exchange was, I thought or hoped, a main purpose of the TC.
I am less concerned with whether anyone really prefers a particular NAPTR DNS functionality, than I am in motivating discussion of which real requirements
need (parts of) BDX in producing specifications of generic applicability to “cloud” business document exchange (like the 4-corner paradigm).
From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Monday, October 31, 2011 9:07 AM
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:
|
mike_edwards@uk.ibm.com
|
|
|
|
|
|||
|
|
|||
|
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:
|
<bdx@lists.oasis-open.org> |
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