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


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

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

Subject: RE: [bdxr] Generalizing metadata service discovery mechanism using DNS capabilities

Thanks for your comments, and I understand the distinctions you make (I think!)  I am interested in generalization along all the dimensions of the URI used for a “metadata service”. The metadata service would seem to me to be a possible generalization of SMP concerns, while a NAPTR generalizes some aspects of SML. It seems to me that parts of SML and SMP will be “special cases” of the NAPTR scheme, and it will of course take some time to fully survey what new options can be accomplished, what supplementary tasks of standardization emerge,  and how to fit in other approaches (found in REST, WS and ebXML, for example) into the discovery pattern enabled by the “u” NAPTRs. (I won’t be addressing the “management interface” in SML tomorrow at all, by the way.)  I expect that over time, and with new use cases, there will be a need to consider several ways to “slice and dice” functionality connected with PEPPOL discovery and services.


From: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] On Behalf Of Kenneth Bengtsson
Sent: Tuesday, May 15, 2012 1:01 PM
To: Moberg Dale; bdxr@lists.oasis-open.org
Subject: Re: [bdxr] Generalizing metadata service discovery mechanism using DNS capabilities


Hi Dale


Thanks for the very interesting document, and I'm looking tremendously forward to your presentation tomorrow!


Just to few clarify that the SML and the SMP are two different specifications, without any mutual dependencies. In slide 3 you describe the address for service metadata as:

http://<hash over recipientID>.<schemeID>.<SML domain>/<recipientID>/services/<documentType>


Note that only the hostname part ("<hash over recipientID>.<schemeID>.<SML domain>") belongs to the SML specification. The path ("/<recipientID>/services/<documentType>") is part of the REST interface described in the SMP spec.


Keeping this distinction between SML and SMP may actually answer some of your questions in slide 4:


2) Can the hostname part convention be altered?

We can definitely change the SML hostname convention without changing the SMLP architecture and without concern for SMP. I essentially agree with you that the SML specification is very hardcoded the PEPPOL mindset where there is one central authority governing the users of the architecture. A more flexible/generalized approach, such as you describe, will in my opinion be appropriate.


3) Can there be many different SMP domains?

In the PEPPOL architecture there essentially already are many different SMP domains. SMP providers are running their services under their individual domain names. The SML hostname under the <SML domain> is just an alias for their respective hostname under their respective domain. I agree with you that using the SML domain alias will cause problems if used with https.


4) Can different communities use different paths?

Paths, no. The path is part of the SMP REST scheme. But different communities can use different SML domains. This was part of the original PEPPOL vision, that you can replicate the entire architecture to a different community just by setting up a new SML/DNS service. The current setup does however require that you have some sort of central institution to run the SML service and to decide who can register their services, which may not fit all requirements and use cases.


Best regards,





From: Moberg Dale <dmoberg@axway.com>
Date: Monday, May 14, 2012 9:26 AM
To: "bdxr@lists.oasis-open.org" <bdxr@lists.oasis-open.org>
Subject: [bdxr] Generalizing metadata service discovery mechanism using DNS capabilities



Please find attached a proposal on a way to discover a URL for a service that could provide connectivity capability ( metadata)  for  internet accessible “X2X “  interactions.


Some of the underlying standards may not be familiar, and if you have time,  here are some background links




An early application in the commercial supply chain (“internet of things”)  (now being updated to the “FONS” standard)




Dale Moberg






--------------------------------------------------------------------- To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org For additional commands, e-mail: bdxr-help@lists.oasis-open.org

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