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


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,

Kenneth


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

 

http://en.wikipedia.org/wiki/NAPTR_record

 

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

 

http://www.gs1.org/gsmp/kc/epcglobal/ons/ons_1_0_1-standard-20080529.pdf

 

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]