[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [bdxr] Business Identifiers -- was RE: [bdxr] Groups - Service Discovery Generalization with NAPTR(u) uploaded
|
(copy to the list) Hi Kenneth, I had been thinking of the URL that is used for contacting the metadata service as having a template that was mentioned in the quoted paragraph from part L.
The paragraph states the two things need to be supplied (encoded bus. Id and schema) plus the smldomain. For me, the dotted hostname part of a URL is a DNS string. The URL has scheme plus hostname plus path plus parameters. I guess we should have a vocabulary section
and agree on the terminology! When I talk about the URL, that string will have substrings from DNS, from the URI specs (HTTP, HTTPS, etc) and possibly a path and possibly parameters.
A pure REST approach for query is—again for me—using the GET method, followed by the URL. Roger wanted path or parameters to be used to specify, well, anything
that needs specification to get the desired result from the metadata service. I think Pim wants to be able to use a POST method, and use the message body to provide a request to the metadata service. From the point of view of Location of service discovery, either or both of these ways of proceeding can be supported. One thing that non-automated systems will very probably need is a registration service, that among other things, sets up the credentials that will be used
in accessing the metadata service (a querier needs to be authorized). Again, all this would need to be specified
out. I used “template” just in the sense of a pattern that must be followed to produce a URL. In PEPPOL, a specific choice is made on what parts of the template
are variable. For a generalization, any part of the URL may be varied and stored in the NAPTR. Whether we also want to “post process” the NAPTR value that we retrieve is an open question. I would prefer to let other groups defining metadata services (to set
up their business interactions) to then define “how” their retrieved values are translated into specific queries. They can follow REST patterns, or WS patterns, or ebMS patterns, and probably others as well. I am only proposing that we consider a NAPTR generalization
for the URL retrieval (at the moment). That means (in my opinion) that whatever use cases come up that uses internet communication technologies as specified by URLs, we can locate the resource. I think that what I am saying is terminologically consistent with the L,M,N parts of PEPPOL. If you prefer to put it otherwise, please formulate your wording.
But I do wish to generalize the PEPPOL approach to take advantage of DNS storage of metadata service URLs. [There are in fact more elaborate uses of DNS records to store services. But I hope that the NAPTR trick is all that is needed to use within BDXR. I
will not add to the confusion by mentioning other generalizations of NAPTR at this point, however! You are all welcome to wade through the RFCs in the dynamic discovery series of RFCs if you want to find additional options!] Hope that helps, Dale From: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org]
On Behalf Of Kenneth Bengtsson Hi Dale Thanks for your explanation. Just a supplementary question before I send you my list of followup questions ;-) When you say "SML template", are you referring to the hostname format as used in PEPPOL (encoded-business-id.smldomain) or do you refer to the REST interface
for the SMP service (the path part of the SMP URL)? I think you are referring to them both in combination. Best regards, Kenneth From:
Moberg Dale <dmoberg@axway.com> Hi Kenneth, I will respond to your: Question: How do you see the use of business identifiers? Can existing business identifiers (GLN, VAT etc.) fit into this scheme? Let me first review what the generalization (and its illustration with NAPTR-“u” implementation) is to allow. The goal is to find a backwards compatible approach
that allows the URL for a metadata service to be retrieved from the DNS, rather than always constructed from filling in a template. The service location discovery is now done by a query to DNS for NAPTR records. These queries (which can be explored with a
tool like “dig” in a linux system (that is configured to make use of some decent DNS servers!) ) can then use a fully qualified host name or a domain name or, in fact any DNS admissible query string) So instead of requiring what SML domain is relevant to a metadata service, it becomes possible to simply use a company’s registered DNS name, for example, in
the query. DNS names are one kind of company identifier. And this permits a company to run its own metadata service, if it wants to. Or even if it wants to outsource either its DNS or its metadata service, one could still find that service entry point by querying
for its NAPTR at big-financial-institution.com, and the value could be for a metadata service provider hostname (outside big-financial-institution.com) at meta-cloud-systems.tld, for example. The HTTPS schema could then know what hostname to look for, and
the remote endpoint could be identified by its certificate (or TLSA record or combination thereof) as the intended service host. By using TLS, we can use some of the “lightweight” authorization approaches needed for Roger Bass’s use case); these include OAuth
using Bearer tokens in the Authorization header as well as ordinary Basic Auth (username/password). [These approaches assume and should require protection by TLS (IMO).] Roger’s use case raises an additional question about registration with the server, and
this raises a question about registration service discovery. I have not yet found much (official) standardization in the registration service discovery area. Most of these are browser-based and you discover them by a little control marked “Register” ! But
let’s move beyond the preliminaries, and ask: well how does the metadata discovery service “know” whose metadata you are interested in? I think this is the question that is of interest to you; if not, please ask again! Roger has also asked how to query the URL found during metadata service location discovery. And here we can make use of the parts of a URL after the hostname—that
is, after scheme://example.com/path/parts/as/needed?queryp0=value&morequery=othervalue& as needed. These parts of the URL are URI-escapable, or the SML implementation of hashing names and naming-authority schemes, can also be used in the path components.
It makes sense to me to put them in the path components, because certainly that will be a crucial “key” for the metadata values that are to be retrieved. I suppose they could be put into the query parameters (keys, or key-value pairs) also. Those choices are
TBD. For example, if ebXML were to use this device, we would probably want to arrive at enumerations of supported values and parameters that would enable CPPs to be retrieved, or parts of CPPs, and so on. [Also there would need to be room for a RegRep metadata
service, and what is needed there is really TBD in collaboration with that TC.] In addition,because the NAPTR system is backwards compatible with SML/SMP, the NAPTR values can contain the same URLs as now used. For CPP, we have over the years built up a
mapping of ISO identified naming authorities and values within those naming authority systems that can be leveraged directly or with abbreviations that could fit into URL path components or into URI-escaped query value fields. Pim is the ebXML expert on the
current state of these enumerated values, and ebCore is a discussion area for the work in that specification. So I will let Pim speak on any specifics about that specification about business identifiers. If there is something that we missed in the business
identifier area, it is probably because it has emerged recently or was not added to the ISO base codes.
http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/PartyIdType-1.0.html 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? I think I have addressed this question in the above. The NAPTR can contain the “filled-out SML template” (In this use case, you would also need to know the
domain part for a given metadata service provider arena.) If you, however, know the filled-out URL, the NAPTR is arguably a little redundant (and this is deliberate so that backwards compatibility is possible.) Where the generalization starts to show its
value, is for future systems that might involve a federation of SML/SMP systems across many domains or different naming systems, for systems that make use of different metadata formats (such as CPP or WS-Policy/WSDL or whatever is next) , or have different
metadata service access requirements. And there are also some security features that allow emerging security approaches (DANE, TLSA, DNSSEC signatures over NAPTRs, etc.) to be utilized a little more cleanly. Currently some of these security approaches are
awkward when the service hostname is a CNAME, for example. I hope this helps clarify the naming problems involved both with DNS names (a core naming identifier system when internet is involved) as well as the business
naming authority names (like GLNs, DUNS, ISO 20222, etc. etc.) that are needed in the query to the metadata service. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]