[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Action required: RE: [wsrp-pfb] Re: UDDI partition names convention
The review/objection/comment period is over. Therefore we consider the proposal below as adopted. @Luc: Let's take the next steps in the process and proceed with the registration. Can you comment on the next admin steps? We can also take this process offline. It would be great if we could make this a done thing before our WSRP F2F in the first week of October. I greatly appreaciate your support and assistance. Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development WSRP Team Lead & Technical Lead WSRP Standardization Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com "Luc Clement" <luc.clement@syst inet.com> To Richard Jacob/Germany/IBM@IBMDE, 08/23/2005 04:56 <wtcox@comcast.net>, AM <jamie.clark@oasis-open.org> cc "'Rich Thompson'" <richt2@us.ibm.com>, <wsrp-pfb@lists.oasis-open.org>, <uddi-spec@lists.oasis-open.org> Subject Action required: RE: [wsrp-pfb] Re: UDDI partition names convention Bill/Jamie: action required. See below. Luc Clément | Program Director | Systinet Corporation | Co-Chair OASIS UDDI TC One van de Graaff Drive Burlington, MA 01803 Phone +1 781.362.1330 | Mobile +1 978.793.2162 | Fax +1 781.362.1400 | _____________________________________________ From: Richard Jacob [mailto:richard.jacob@de.ibm.com] Sent: Monday, August 22, 2005 06:04 To: wtcox@comcast.net; jamie.clark@oasis-open.org Cc: Luc Clement; 'Rich Thompson'; wsrp-pfb@lists.oasis-open.org Subject: [wsrp-pfb] Re: UDDI partition names convention Jamie, Bill, I would like pick this up again. I (and I assume Luc neither) haven't heard back from you on this topic. [<lc> Correct</lc>] We really should close on this. As discussed and suggested Luc and I provided you a section for the OASIS nameing guidelines which regulates the UDDI partition nameing conventions. [<lc>I'm eager to close on this. As far as I'm concerned, unless I hear otherwise, this matter is closed and we will proceed as recommended - per note below. </lc>] Again, the key in this proposal is that OASIS - as the natural root for all TCs - owns a UDDI root partition and that TCs willing to use and register UDDI artifacts own a partiton below the OASIS root partition and manage them on their own (see the proposed section below). I have the following questions: - can this section be incorporated into the OASIS nameing guidelines document? [<lc> absolutely! </lc>] - if the answer to the above is yes, when do you expect this to happen? - is OASIS willing to own the root partition, and thus enable us (the WSRP TC) to finally register out tModels into the UBR? [<lc> this is straightforward - we should proceed as if this is done-thing… (ok so I may be jumping the gun here) </lc>] - when do you expect this to happen? [<lc> we've been at this too long - Bill/Jamie as far as I'm concerned this is a done thing, you simply have to add it to the OASIS naming guidelines. Proposal below; we can work out admin issues off-line.</lc>] We're unfortunatly stuck with this since October last year. We need to publish the WSRP tModels into the UBR to make our WSRP UDDI technote practically usable. [<lc> Richard: don't be held back by the UBR publication - take this as a given, we can make this happen as a matter of course. What we need to agree on - which as far as I'm concerned as stated above, this is a "done thing" - is the partition prefix.</lc>] If we can't agree on this proposal and try to make it real in a reasonable timeframe I will suggest to the WSRP TC to use our own WSRP root partition and skip the idea of having a common OASIS UDDI convention. We can't wait forever and block our publish/find/bind scheme because of nameing conventions. [<lc>Bill/Jamie: unless you object soon, uddi:oasis-open.org:{tcShortName}:keygenerator has been adopted. </lc>] Here is again the proposed section for convenience: 6.4 UDDI V3 key partitions and keys The UDDI v3 key syntax described in this section conforms to the UDDI Version 3.0.2 specification's sections 4.4 and 5.2.2. OASIS owns a UDDI v3 key partition. TCs requiring a UDDI v3 key partition for use in attribution of UDDI v3 keys SHALL request a UDDI v3 key sub-partition of the OASIS partition. To register a sub-partition a key generator tModel with the key uddi:oasis-open.org:{tcShortName}:keygenerator SHALL be used. Once attributed to the TC, the TC will become the owning authority of this sub-partition and MAY publish UDDI entities (e.g. tModel) using keys generated from this sub-partition. tModel keys MUST follow the syntax uddi:oasis-open.org:{tcShortName}:KSS (Key Specific String) and MUST conform to UDDI specification 3.0.2, section 4.4. Key partitions can be requested by contacting the OASIS staff who will handle the registration of these UDDI v3 key partitions. Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development WSRP Team Lead & Technical Lead WSRP Standardization Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com Richard Jacob/Germany/IBM To 07/18/2005 11:57 William Cox <wtcox@comcast.net> AM cc Luc Clement <luc.clement@systinet.com>, "'Rich Thompson'" <richt2@us.ibm.com> Subject Re: UDDI partition names convention (Document link: Richard Jacob) Bill, see my comments inline. I'm not sure what you are suggesting, most of the questions seem not to relate to the section we propose. Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development WSRP Team Lead & Technical Lead WSRP Standardization Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com William Cox <wtcox@comcast.ne t> To Luc Clement 07/15/2005 09:27 <luc.clement@systinet.com> PM cc "'Rich Thompson'" <richt2@us.ibm.com>, Richard Jacob/Germany/IBM@IBMDE Subject Re: UDDI partition names convention Luc et al -- First, what are you expectations that URNs can be resolved? The typical use of URNs is to define a unique name, but not necessarily one that can be resolved. (In fact, AIR currently suggests, in effect, that you use URLs/URIs not in the urn scheme if you expect resolution - the resolver implied in RFC 3121 is not apparently implemented. Of course, the URNs could be translated into the http scheme for resolution. The typical use for URNs is XML namespace definition, which does NOT require resolution.) So what are your expectations on whether the URNs can be resolved? <rj> don't understand your comment and what you're targetting at. I think Luc didn't have the expectation here </rj> The approach in our email thread looks good to me (the first form). As far as the Artifact Identification Requirements, I'd prefer to delegate the details of the uddi key space to the uddi-spec TC, simply reserving (from the OASIS and TC perspective) the root of that space. I think that this is in the spirit of RFC 3121, which establishes the urn, and leaves the details of the structure to the respective TCs and TC Admin. Thus the uddi-spec TC would publish a technical note on the structure of keygenerators in the urn scheme. Richard's note suggests that every TC SHOULD or MUST have a keygenerator subspace. Which? <rj> no, in only applies for TCs intending to have their own subpartition. If they want to have one, then they should follow the procedure described. The partition name contains the tc shortname... that one. </rj> If keygenerator is strictly for uddi, should it not be called something like "uddi-keygenerator" or "uddiKeyGenerator"? How universal is this need? enough to reserve that name in every TC's address space? How are other standards groups addressing this perceived need? I have no problem with this if the name is uddiKeyGenerator (or some such), as the likelihood of collisions with other TCs is nil. "KeyGenerator" is more problematic in reserving a namespace. <rj> the keyGenerator is a tModel key rather than a namespace, see the uddi spec sections I mentioned in the paragraph. I thing changing them is not necessary or even desireable at all. Besides this the keyGenerator tModel is registered in the in the {tcname} partition, therefor is safely namespaced. </rj> Why should OASIS staff and not the respective TCs manage the respective uddiKeyGenerator spaces? I'd like to reduce administrative burden on OASIS and place it on the TCs that are actually using this capability. <rj> Well, because it's hierarchical, and OASIS is our natural root. Once the sub partition is registered TC becomes the owner and can register its tModels. That's all it is about. If you want to get rid of the OASIS root, every TC would register its own root and keep OASIS out of this game. I'm generally fine with that. (In genral I'm fine with every convention we come up with, I just want to make our stuff work - we're blocked for 9 months now!) If you want to go that route I would propose to register uddi:{tcShortName}.oasis-open.org:keygenerator and use keys like this uddi:{tcShortName}.oasis-open.org:KSS (Key Specific String) </rj> In effect, you'd like to establish a convention that ...:uddiKeyGenerator:... be reserved in the namespace for each OASIS TC. If this is a convention on which the public can rely, it should be considered for the [proposed] update to RFC 3121, although for the near term OASIS can establish such a convention. I agree that we should "avoid putting in this document the methodology used." The rest of the AIR typically says things like "selected by the TC with TC Administrator approval" for such things. I don't want any details tied to (e.g.) v3.x of UDDI in this document. <rj> that's fine </rj> How would the keygenerators evolve over time? Again, I'd like to establish a structure in which the TCs manage any keygenerators, and their evolution. If version 4.x of uddi-spec requires something different, will you need to include (e.g.) something like uddiKeyGenerator:v3: and uddiKeyGenerator:v4? <rj> no, see UDDI spec </rj> bill Luc Clement wrote: Rich - I didn't see any inline comments in your note. _____________________________________________ From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Monday, July 11, 2005 06:49 To: Luc Clement Cc: 'Richard Jacob'; 'William Cox' Subject: RE: UDDI partition names convention We should settle on whether the attribution of keyspaces should follow the Form One or Two of the URN below. << OLE Object: Picture (Enhanced Metafile) >> Keyspace introduce an ownership facet to them which argues for the use of {tcShortName}. I propose that these key spaces be attributed by the OASIS staff; I'd like to avoid putting in this document the methodology used. Thus, here is the proposed revised text: -- Luc 6.4 UDDI V3 key partitions and keys The UDDI v3 key syntax described in this section conforms to the UDDI Version 3.0.2 specification's sections 4.4 and 5.2.2. OASIS owns a UDDI v3 key partition. TCs requiring a UDDI v3 key partition for use in attribution of UDDI v3 keys SHALL request a UDDI v3 key sub-partition of the OASIS partition. To register a sub-partition a key generator tModel with the key uddi:oasis-open.org:{tcShortName}:keygenerator SHALL be used. Once attributed to the TC, the TC will become the owning authority of this sub-partition and MAY publish UDDI entities (e.g. tModel) using keys generated from this sub-partition. tModel keys MUST follow the syntax uddi:oasis-open.org:{tcShortName}:KSS (Key Specific String) and MUST conform to UDDI specification 3.0.2, section 4.4. Key partitions can be requested by contacting the OASIS staff who will handle the registration of these UDDI v3 key partitions. -----Original Message----- From: Richard Jacob [mailto:richard.jacob@de.ibm.com] Sent: Thursday, July 07, 2005 06:03 To: William Cox Cc: Luc Clement; Rich Thompson Subject: Re: UDDI partition names convention Bill, here are my comments. I think we miss a section about UDDI keys and partitions. I would suggest to add a section 6.4 as follows. @Luc, could you please also review and comment. Line 465-533: Problem description: we miss a convention for uddi keys maintained by OASIS TCs. We should have one common OASIS UDDI partition with sub partitions for each TC. This way we keep them tied together. Proposed solution: add UDDI key and partiton section Proposed text: __________________________ 6.4 UDDI V3 partitions and keys The key syntax described in this section conforms to UDDI specification 3.0.2, section 4.4 and section 5.2.2. OASIS owns a UDDI partition. TCs willing to publish tModel keys to the universal business registry (UBR) SHALL register UDDI sub-partitions beneath the OASIS partition. To register a sub-partition, a key generator tModel with the key uddi:oasis-open.org:{tcname}:keygenerator is registered. The TC becomes the owning authority of the sub-partition and MAY publish its tModel keys into that sub-partition. tModel keys MUST follow the syntax uddi:oasis-open.org:{tcname}:KSS (Key Specific String) and MUST conform to UDDI specification 3.0.2, section 4.4. ---------------------------------------- This would also imply that we register the OASIS root partition. Luc, how could we proceed with this? I would really like to finalize this soon, as our WSRP UDDI technical note is now for nearly 1 year on hold! We need to publish our tModel keys ASAP to make the tech note work. The alternative I see is that the WSRP TC registers its own, disconnected partition instead. Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development WSRP Team Lead & Technical Lead WSRP Standardization Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com Rich Thompson <richt2@us.ibm.co m> To William Cox <wtcox@comcast.net> 06/27/2005 03:15 cc PM Luc Clement <luc.clement@systinet.com>, Richard Jacob/Germany/IBM@IBMDE Subject Re: UDDI partition names convention Minor nits I noticed: - Line 436: Missing a quote - Line 482: I think it should be " defined in Section 5.2" - Line 500: "Specificaton" should be "Specification" I will leave a detailed review of how Section 6 would apply to UDDI urns to Richard and Luc. Rich Thompson OASIS WSRP TC Chair Interaction Middleware and Standards for Portal Server IBM T.J. Watson Research Center / Yorktown Heights, NY Phone: (914) 945-3225 / (203) 445-0384 email: richt2@us.ibm.com William Cox <wtcox@comcast .net> To Luc Clement <luc.clement@systinet.com>, 06/23/05 04:13 "'Richard Jacob'" PM <richard.jacob@de.ibm.com>, Rich Thompson/Watson/IBM@IBMUS, tony.rogers@ca.com cc "'James Bryce Clark'" <jamie.clark@oasis-open.org>, Pete Wenzel <pete@seebeyond.com> Subject Re: UDDI partition names convention I'm attaching a current review version of the TAB's Artifact Identification Requirements; the proposed namespace for TC use is in Section 6 along with other URN-related issues. This is a pre-review; before a broader member review. If possible, comments by June 30 would be most useful, and in the format requested. I'm extending the pre-review to you as the motivators of some of the changes. (both uddi-spec and wsrp) Please contact me by phone or email as needed; review comments to me, please. Thanks! bill cox 908 277 2499 home 862 485 3696 cell wtcox@comcast.net Luc Clement wrote: Sorry for jumping in late on this thread - I've been traveling (a lot). I think we need to bear in mind the original intent - not to say that we've diverted from it. In short, what is required is the attribution of a keyspace for use by OASIS that can be further partitioned for the TC. As James points out, the UDDI URI scheme has been registered ("UDDI URI Scheme Registration with IANA") though for some reason it is still not available. I think that this answers Bill's Issue 0 and Issue 1. As for Issue 2, Bill suggests the use of "uddi:oasis:tc:uddi-spec:generators:keygenerator". 1) the key is intended to be domain based - i.e. a DNS domain is used to self-regulate the assignment of keys at the top level of the keyspace. As such, the key MUST be in the form of "uddi:oasis-open.org:<something>(<:something><:...>):keygenerator". And 2) this won't also do given that keygenerator is used to reserve the keyspace to the left of ":keygenerator". What we need are keys in the form of "uddi:oasis-open.org:tc:uddi-spec:myfirstkey" rather than "uddi:oasis:tc:uddi-spec:generators:myfirstkey". I don't particularly care what we end up in terms of structure between "uddi:oasis-open.org" and ":keygenerator" as long as its workable and hierarchical so that TCs that need to partition a part of the keyspace can do so easily. As it relates to registration of these, the UDDI member section has set up a simple registration process - details at http://uddi.org/tmodels.html. This might suffice for now but won't scale necessarily - we can address this as a second order matter. Luc -----Original Message----- From: Richard Jacob [mailto:richard.jacob@de.ibm.com] Sent: Thursday, March 17, 2005 05:56 To: James Bryce Clark Cc: luc.clement@systinet.com; richt2@us.ibm.com; tony.rogers@ca.com; wtcox@comcast.net Subject: Re: UDDI partition names convention Before I comment on question to Bill: Bill could you please provide us the latest document, I still didn't receive it. James Bryce Clark <jamie.clark@oasis-open.org> wrote on 16.03.2005 07:06:07: Regarding the following: Therefor I would choose the > URL-like syntax: "uddi:oasis-open.org:owner" where owner is the TC name. (section 7.3 of this documents has some similar examples). To overcome the limitation of having OASIS their own tModels we could have a "oasis" partition similar to the other TCs' partitions.. So I would propose to: 1. register uddi:oasis-open.org:keygenerator 2. register uddi:oasis-open.org:oasis:keygenerator (if OASIS feels they need it at that time) 3. register uddi:oasis-open.org:uddi-spec:keygenerator 4. register uddi:oasis-open.org:wsrp:keygenerator" Luc and I agreed that this should be stuck in the UDDI and WSRP TC only but rather than this to add this convention to the OASIS nameing guidelines document and add a UDDI section there. * * * Without this convention the WSRP TC is stuck with publishing the WSRP tModel to the UBR and therefore is blocked of publishing our "Publish/find/bind" technical notes. I think the foregoing plan generally makes sense. The act of registration itself may raise a few other issues. I have the following concerns. For Richard and WSRP: 1. I understand the foregoing proposal to be a production rule for uddiKeys for OASIS specifications, thus necessarily compliant with the v3.0.2 spec's section 4.4.1. Please advise if I am wrong. correct 2. I understand that this would allow registration of those tModels into any globally unique naming scheme ... which includes, but is not limited to, the UBR, a resource with which OASIS is not affiliated. Should we register OASIS tModels there? Richard has suggested we need not do so. I would like to better understand that. well, registering tModels into the UBR is simply making them public, associating them with the spec/tech note and make them resusable and interoperable for all parties. The specific usage of the tModels is described in in the WSRP UDDI technote, but in general conform to any other usage of tModels UDDI registries. This is the only feasible way how we can establish a common, interoperable scheme for finding und publishing WSRP services and fragments into a global registry. Some UDDI users may use the UBR; others may not. It is not clear to me whether registering OASIS spec tModels in the UBR confers some kind of primacy that would pre-empt their representation in other UDDI directories. well, the need to be global unique in the UBR, otherwise there is no interoperability. This is the same as you would say an OASIS namepsace in an spec-defined xsd would pre-empt its use. Concerning the other UDDI directories: For private directories their owner need to publish similar keys defined in the technotes to be able to use the scheme specified. Some of the pre-defined UDDI tModels and their keys make it into UDDI products and thus private registry, some not. This is standard UDDI handling here. (If it works like the DNS cloud -- write once, promulgate everywhere -- that may be fine. But if it is analogous to an ISP -- where your address is associated with one and only one vendor or directory -- it could be inappropriate for us.) I apologize that I do not know enough about the UBR's functioning to be certain of this. I think it's not. All we do in short words is the following: We define a publish/find/bind scheme for WSRP entities and describe the use of the scheme by using standard UDDI mechanics. For convenience and interoperability we publish the tModel we need to make to model work into the UBR and thus make it globally known and common. We say: "You can use the same scheme in your private UDDI registry also in an interoperable manner, all you need to do is to follow the model we described and publish the tModels we defined into your registry. Then your applications are able to use our defined publish/find/bind scheme." 3. If there is metadata associated with a tModel registration that points to an owner person or entity, I need to confirm the proper values for those values. The owner of a partition will be the TC. For UDDI: 4. We have not completed our renovation of the OASIS namespace rules (RFC 3121) yet. However, the general idea of concatenating an identifier for OASIS (e.g., "oasis") with that for a TC's unique ID (e.g., "uddi-spec" or "wsrp") is likely to survive intact. The proposal above seems broadly consistent with this approach. I acknowledge Bill Cox's point about the possible extra element "tc" (as in uddi:oasis-open.org:tc:wsrp:etc.) being more aligned with 3121, which uses a "names" element. But I am inclined to agree with Richard that it's superfluous. If we wish to enable OASIS-sourced tModels for something that is NOT owned by a TC, we can solve that with some unique element as a prefix that is NOT a TC name. As in uddi:oasis-open.org:oasis:etc. 5. I have been unable to confirm the ultimate disposition of the "UDDI URI Scheme Registration with IANA" prepared for the UDDI Spec TC by Andrew Hately in late 2003. I don't see it listed at IANA (see http://www.iana.org/assignments/urn-namespaces) and am not certain how this ultimately has been factored in. 6. It remains that the uddi:xxxx space is not part of OASIS's RFC 3121 space. Someone in this thread pointed out that the restatement of 3121 should account for this. Two years ago, in conversations that included Luc and I, OASIS indicated a strong preference for deprecating dependencies on [uddi.org], as we have with all other incoming works that join OASIS. At the time, it was suggested that this was infeasible as to then-v2 and then-v3, so my predecessor conceded the variance as to those two versions. I expect the issue to come up again, now that v3 has completed its approval arc. We should discuss that with the TC as part of the v.Next plans. But I do not see that it changes the conclusions above. Regards JBC ~ James Bryce Clark ~ Director, Standards Development, OASIS ~ jamie.clark@oasis-open.org [attachment "ArtifactIdentificationRequirements-v1.0-wd-14.pdf" deleted by Richard Jacob/Germany/IBM] [attachment "Review of AIR WD 14.pdf" deleted by Richard Jacob/Germany/IBM] --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]