[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: URN resolution background
This off-list email thread relates to the issues we’ve been discussing of what the resolution process would actually look like, and the potential roles of different actors. I’m also referring here to an email I did send to the list before, on Jun-5, subject ‘Use case requirements - service profile registrar models’. As Dale mentioned, the probable real-world scenario is one where different lookup systems exist, without there necessarily being an agreed, centralized governance. This implies that a Discovery/Locator Service client would need to perform a sequence of lookups, starting with the most authoritative and global (if they exist), and then moving to more community-specific services. At the end of the email below, I make a suggestion as to what that might look like. Roger From: Roger Bass [mailto:roger@traxian.com] Pim, Dale, I would support moving this discussion to the BDXR list, but suspect that a further presentation or paper on the topic might be needed to help bring people up to speed. We could discuss with Kenneth perhaps if it made more sense for us to attempt a summary of current thinking first, or just to forward to the list these various emails we’ve each been sending. Various questions and issues occur to me: 1. Dale, you suggested previously that some discussion of registrar roles and validation/verification processes should take place first, and I sent an email to the list with some thoughts on that (Jun-5, service profile registrar models). What are the issues at this more technical level that you see relating to those issues? I can think of several (see below), but want to understand your thinking. 2. Pim, I agree with your observation that ideally each ISO 6523 identity publisher (e.g. GS1) would manage a resolution system for those identities. However, on at least a transitional basis (perhaps fairly long-term for some), it seems to me that community root / governance structures (such as PEPPOL) would be the ones who primarily need such resolution services to be available, comprehensively for all their (supported) ISO 6523 identifiers. That, to me, raises questions of: a. Whether centralized, unified governance is really feasible in the initial phase here? (By that I mean: a set of ISO 6523 resolution services as you describe, where one and only one such service exists for each ICD level). b. If initially, the resolution services that exist are in reality operated by a community root such as PEPPOL, whether we shouldn’t perhaps explicitly state what the actual resolution process would look like? See below for suggestions. c. Whether rules for peering / root data synchronization / conflict resolution are something it makes sense to address in the standards committee context? Or if, realistically, that’s just something the various community roots that emerge would need to figure out amongst themselves? 3. Might we define an extended (and potentially simplified) version of this OASIS / ISO 6523 based scheme to include and leverage standard domain identifiers (i.e. company domain and email)? Per my earlier emails, I think this would need to support the following cases: a. Records that are actually resolved through a company domain record (e.g. cpp.domain.tld or connect.domain.tld) b. Names defined through a some root structure (either unified, or community-specific, but see above for caveats), e.g. i. “cpp.domain.tld.partyid-type.ebcore.tc.names.oasis.arpa.uri” ii. “cpp.domain.tld.partyid-type.peppol.eu.arpa.uri” iii. or ultimately a new “.cpp” or “.connect” tld, e.g. “domain.tld.connect” c. Email addresses defined similarly (for domains that have not been “locked” at one of the levels above), e.g. cpp.email@domain.tld.partyid-type.peppol.eu.arpa.uri, or whatever the correct syntax would be (if “@” is disallowed here) In my Jun-5 email, I also touched on some potential conflict and resolution scenarios, where a business might legitimately authorize two different service providers to publish profiles that conflict or overlap. Realistically in the near-to-mid-term, however, I’m thinking that’s something that the community roots would have to resolve for their own communities. Over time, those community roots might formalize their own rules for that, and then perhaps harmonize those into some unified global scheme. (That might be the point when a new “.connect” TLD could make sense). So, perhaps this implies that clients seeking a CPP for an ISO6523-identified organization might need to perform the following steps: A. If the organization/email domain name is also known, first check cpp.domain.tld (and possibly validate the ISO 6523 identifier there) B. Then check the global (OASIS/ISO6523/domain) structure to see *IF* an official resolution service exists for that identifier (potentially extended to support domain identifiers, as above) C. Then, successively check community-specific versions (e.g. cpp.0088.iso6523.partyid-type.peppol.eu.arpa.uri or cpp.domain.tld.partyid-type.peppol.eu.arpa.uri) Best regards, Roger From: Pim van der Eijk [mailto:pvde@sonnenglanz.net] Hello, Perhaps we should move this discussion to the BDXR list, but here is some feedback: The ebCore Party Id type is based on the URN scheme mentioned below. It then has a level that identifies the meta-classification level (e.g. "iso6523"), an ICD level (e.g. "0088" for GLN) and then an identifier specific to the ICD. So ideally GS1 would host a resolution system for GLNs (e.g. http://gepir.gs1.org/v32/xx/default.aspx?Lang=en-US), ISO would host a resolution system for 6523 and OASIS would resolve the "names:tc:ebcore:partyid-type:iso6523" to the ISO resolution system. Not sure if such a complex structure is needed or desirable. Also not sure if OASIS is willing to manage DNS records in the "oasis.arpa.uri" domain. The DNS search key would probably have to be something like "0088.iso6523.partyid-type.ebcore.tc.names.oasis.arpa.uri" ? The next question is that this is the identifier for the organization, not for its CPP. Would the following work or be appropriate ? "cpp.0088.iso6523.partyid-type.ebcore.tc.names.oasis.arpa.uri" The ".tel" domain resolves identifiers to attribute/value pairs, can "0088.iso6523.partyid-type.ebcore.tc.names.oasis.arpa.uri" resolve to some structure (e.g. a JSON collection) where "cpp" is one name that contains a URI to retrieve the CPP, but there could be other names e.g. to go to the GS1 site to look up the registration information about the identifier in an HTML page, or an email address of a contact person. I think you mentioned that NAPTR records can have attributes to distinguish different aspects, so could "cpp" be a service for the record with the particular ebCore ID ? Pim |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]