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] Groups - Service Discovery Generalization with NAPTR(u) uploaded

Hi Dale

Thanks for your presentation yesterday, which I enjoyed very much. I promised to send you my questions and comments via the mailing list. I guess they can basically be summarized as:

Question: How do you see the use of business identifiers? Can existing business identifiers (GLN, VAT etc.) fit into this scheme? You are right in your comment on slide 3 that in the PEPPOL model, senders are required to know two pieces of information about the receiver: The literal business identifier, and what type of business identifier is being used. So if you want to send a document to a Danish company as example, you will have to know that they are registered in the public records as (for example) DK12345678 and that this number refers to a Danish VAT scheme. This makes a lot of sense for PEPPOL because existing business identifiers can be reused rather than having to reinvent and coordinate. There may also be a certain level of confidence in using some trusted source of identification rather than "my-trading-partner@some-service.some-network". How can this fit into the NAPTR generalization scheme?

Comment: In the PEPPOL SMLP model, the publishing of service metadata is separate and completely decoupled both the transport protocol and the general service discovery. I think this approach adds good value. It has been a way for PEPPOL to create an infrastructure without a "single point of failure" (the DNS/SML aspect) while at the same time having a flexible XML model for publishing and sharing service metadata (the SMP). The orthogonal design also makes it possible to use with whichever transport protocol. I'm far from sure that a DNS record, however intelligent it has been designed, can hold all necessary metadata. If we build the publishing metadata into the transport protocol we create dependencies and lose flexibility. I think it is worth it to see how we can use the "SMLP design" combined with more flexible DNS options.

Best regards,


From: Dale Moberg <dmoberg@us.axway.com>
Date: Wednesday, May 16, 2012 1:00 PM
To: <bdxr@lists.oasis-open.org>
Subject: [bdxr] Groups - Service Discovery Generalization with NAPTR(u) uploaded

Document Name: Service Discovery Generalization with NAPTR(u)

No description provided.
Download Latest Revision
Public Download Link

Submitter: Dale Moberg
Group: OASIS Business Document Exchange (BDXR) TC
Folder: Documents
Date submitted: 2012-05-16 11:00:54

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