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: BDX Addressing Mechanism Requirements

Hi BDXers,


Mike Edwards’ presentation on BDX addressing left me wondering what were the original requirements for the proposed mechanism for the BDX discovery service, and perhaps what were the original goals leading to  the 4-corner model ? It is often useful to understand the problem space for a design before assessing it or considering alternatives. Unfortunately, this leaves many of us who were not participants in a long prior effort at a disadvantage. Nevertheless, I will read off some of the questions that the addressing model “basic system elements” and beyond raise for me.


A  requirement is that the system is to support sending business documents one-way “through” 2 intermediaries called “access points.” The diagram suggests that senders know how to send a message to one access point (possibly more), and how to indicate the ultimate recipient (somehow);  recipients know how to publish some service metadata to a publisher. Important points reveal that participants can be either receivers or senders, a participant has an id of some sort, and the SOAP body has a “document type” (that we later learn has a URI identifier).


Mike’s question was “how does a sender participant find where to send the document?”  From the diagram, the participant needs to send documents to an access point. So one question is how a participant learns the address of the access point, which is as I understand it, done by a registration into the “domain” of an access point. So I think the question Mike is resolving might be: “ how does the access point know which access point to send my document to next?”


At this point Mike takes us  into a detailed solution involving publishing metadata records, querying metadata records, DNS record manipulation, and then finally routing the message.   I lost track of whether the message is always or sometimes forwarded by (SOAP) intermediaries (access points) or whether the sender sometimes or always goes through a metadata query, retrieval and DNS resolution preliminary process, which is then followed by a direct SOAP message to the ultimate SOAP recipient (whose URL is known and resolvable by DNS queries for A RR records.) It is perhaps worthwhile to reflect how other messaging protocols facing problems abstractly similar to BDX make use of DNS.


Both SMTP/POP and SIP, for example, can be thought of as having intermediaries (MTAs or proxies, respectively). In either case, there can be N intermediaries between sender and recipient (so 2 is easy!). An email address has a user identifier and a domain (user@somewhere), and a destination email address resolution involves using DNS by making a DNS query for the domain ( somewhere.topleveldomain.) to retrieve resource records (RR) for MX (mail exchange). The MX and NS (namespace) RR were generalized to SRV records way back when, and SIP, for example, uses SRV records for domains to figure out what proxy/intermediary to contact first. So the problem of finding an intermediary for a domain using a protocol is nowadays often translated into a DNS SRV query whose answer, when successful, often helpfully gives the A address information for the target server (the IP4 or IP6 dotted numerical address).


The above assumes that there is a basic semantic to an address of record (AOR) involving a user identifier and a domain identifier. This leads me to my first question: why has BDX selected an identifier scheme (Universal Business Identifier) consisting of a scheme code and an id “0010:5798000001” and a second, how do I learn these values? I am guessing that these values are the ones I feed to the Metadata Service Providers in some wsdl defined SOAP or HTTP bound message in order to eventually get an address, through steps involving processing metadata info, to get an A record from DNS?


I will spare you from repeating details about how other messaging systems (like MSRP, VOIP, or GS1 ONS for the “internet of things”) leverage DNS, intermediaries, domains, domain level services, user ids, security, auth, and trust.  I would like to understand whether DNS SRV records themselves might give BDX enough redirection to accomplish the routing tricks that are required. But to make this assessment, the requirements for routing, record update frequency, service naming need to be enumerated. In addition, because “content” seems to be involved in routing (besides recipient participant id) will there be a standard  notation for service.doctype values?  (Mike did state that doctype alone is informationally incomplete; “service” here is the qualifier (from the process namespace) that is intended to give an informationally complete identification of the business action offered by the recipient or his agents; the location of this service can presumably come somehow from DNS.)




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