[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]