OASIS Open Mailing List Archives  ·  All Lists  ·  bdxr  ·  2012-05

bdxr — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

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 [email protected] . 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, Kenneth From: Dale Moberg < [email protected] > Date: Wednesday, May 16, 2012 1:00 PM To: < [email protected] > 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]  |  [Month Index]  |  [List Home]