OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bdx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [bdx] BDX address recipe outline.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]