Minor comment: r ereading Dale's spec and
https://tools.ietf.org/rfc/rfc4848.txt , there are some errors in the sample data I provided, including at least: NAPTR( '2228f94745c706c63e24dcbb705144df16202dfa.production.metadatadomain', 10, 1, 'U', 'service', '', 'http://somedomain.de/service.xml', 1000 ), which should rather be something like: NAPTR( '2228f94745c706c63e24dcbb705144df16202dfa.production.metadatadomain', 10, 1, 'U', 'x-meta:x-smp2, ''!.*!http://somedomain.de/service.xml' , '', 1000 ), as in this case the URI is set in the regexp field and not the replacement field and the service field needs to have a : separating service and protocol, with a x- prefix for experimental services and protocols. From:
bdxr@lists.oasis-open.org [mailto:
bdxr@lists.oasis-open.org] On Behalf Of Pim van der Eijk Sent: 27 March 2013 17:20 To:
bdxr@lists.oasis-open.org Subject: [bdxr] Sample code and test data for Dynamic Discovery Hello, Dale Moberg has provided a draft specification on Business Document Metadata Service Location Discovery to BDX (
https://www.oasis-open.org/apps/org/workgroup/bdxr/download.php/47815/BDX-Location-v1.0-wd02.odt ) that is a further development of the SML concept. He also created some sample client code that works with a sample DNS records used for SIP Internet Telephony and more recently on a browser client example. I wanted to create some DNS data of the required type (NAPTR records of the U type) that I could use for prototyping. Others may find this useful as well, so this email explains how to do this and some sample code and data. A very simple way to create a DNS server that serves NAPTR records is to use Twisted Names (
http://twistedmatrix.com/documents/current/names/howto/names.html ), a DNS server that uses the Twisted toolkit (
http://twistedmatrix.com/trac/ ). Twisted currently requires Python 2.7 and can be downloaded from
http://twistedmatrix.com/trac/wiki/Downloads . Twisted Names is used by some large DNS production sites. But in this email the focus is on a simple DNS server that a developer can run locally on his laptop or some LAN server and that does not interfere with the regular DNS services in his/her office. Installation of Twisted provides a Twisted daemon called twistd , which can be used to create an out-of-the-box DNS server with no coding: twistd -n dns --pyzone <configfile> Here, configfile (in the attached ZIP it is called samplezones.dat ) is a text file containing DNS record data in a simple Python format. (The format of the BIND DNS tool is supported too). It has text records such as: CNAME('www.example-domain.com', 'example-domain.com'), CNAME('ftp.example-domain.com', 'example-domain.com'), MX('example-domain.com', 0, 'mail.example-domain.com'), A('mail.example-domain.com', '123.0.16.43'), NAPTR( 'govello-1234567890123-456789012.production.ecodex.eu', 10, 1, 'U', 'meta', '', 'https://somedomain.de/productionservice.xml', 1000 ), NAPTR( 'govello-1234567890123-456789012.test.ecodex.eu', 10, 1, 'U', 'meta', '', 'https://somedomain.de/testservice.xml', 1000 ), NAPTR( '2228f94745c706c63e24dcbb705144df16202dfa.production.ecodex.eu', 10, 1, 'U', 'service', '', 'http://somedomain.de/service.xml', 1000 ), NAPTR( 'metadata.example-domain.com', 30, 1, 'U', 'ebcpp3', '', 'https://lastditch/cpp.xml', 1000 ), NAPTR( 'metadata.example-domain.com', 10, 1, 'U', 'ebcpp3', '', 'https://somedomain/cpp.xml', 1000 ), NAPTR( 'metadata.example-domain.com', 20, 1, 'U', 'ebcpp3', '', 'https://failoverdomain/cpp.xml', 1000 ), NAPTR( 'metadata.example-domain.com', 1, 1, 'U', 'smp2', '', 'https://otherdomain/smp.xml', 1000 ) The CNAME record type is the type of DNS record used in the PEPPOL SML. I'll not discuss those as Dale's spec explains that NAPTR records are the more appropriate records for the business service discovery scenarios that we're interested in in BDXR. But someone interested in supporting the older SML records in a metadata service in addition to the newer format could use the same server toolkit. The NAPTR records show examples of various service formats (e.g. smp2 or ebcpp3 ), of domain names normalized by hashing and/or with service provider or community domains, and for communities that provide separate branches for separate environments (e.g. production or test ). As already explained in Dale's draft, there are many options and the good news is that it is not difficult to provide multiple options in parallel. A service provider or community could easily provide support for various formats (using different string values for the service field) or various versions of these formats (using version number suffixes). On the client side, I've also enhanced Dale's example that used the dnspython library (
http://www.dnspython.org/ ) and verified that it worked with NAPTR U records, and a nd generalized it somewhat to support an ability to filter search based on service, do searches in community domains and specific environments in these domains, optionally apply normalization using hash algorithms etc. There is the beginning of a library module in the attached ZIP. The main lesson is that a combination of naming conventions, service typing and simple parameterization in toolkits would make it very easy to support multiple publication and discovery scenarios, protocol formats and data formats simultaneously (either permanently or temporarily, during a migration to a newer version of protocol), as far as the initial discovery is concerned (SML, DDDS), without any business impact. The fact that there is an installed base of users of a first version of a discovery protocol and format is no reason not to consider newer protocols and formats even if they are not backward compatible. A full explanation would also cover the service description formats (SMP and others), I hope to cover that during our face to face meeting. Enjoy, Pim