OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[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


Title: 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]