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: RE: [uddi-spec] Groups - uddi-spec-tc-tn-understandingkeypartitions-20030602.doc uploaded


Title: RE: [uddi-spec] Groups - uddi-spec-tc-tn-understandingkeypartitions-20030602.doc uploaded
Both the spec, and the TN, use the term partition in the same way, including all "child" partitions within the "parent". Your quote of my e-mail is incomplete, because I was at pains to point out that it includes keys derived both directly and indirectly - without that qualification it is easy to imagine that it only includes directly derived keys. The spec says the same thing, but in other words. We are working on improving the TN (it is still draft), and we do intend that it reflect the content of the spec. Andrew and I will look at the places you point to.
 
There is a distinction between a publisher having ownership (in some loose sense) of a partition, and the publisher having published the key generator tModel for that partition. The spec only requires the "loose" ownership concept for a publisher to publish a key generator. I do not like this idea, which is the reason I outlined a more restrictive approach - at the face-to-face meeting it became clear that I am not alone in preferring this.
 
Note that there is no way for a publisher to own the partition in which domain key generators lie, because they are not in a partition. Thus it is impossible to completely eliminate the "loose" approach - someone must publish domain key generators. I suggest that this ability be restricted to some kind of administrative publisher, who can then transfer them to the publishers who want them - this kind of restriction is the province of registry / node policy. Once we get past the domain keys, however, everything can operate more cleanly, in the way that I prefer (and I gather you do, too), with only the publisher who owns the key generator tModel for a partition permitted to publish new keys from that partition.
 
I'm about to leave for the airport, so please understand that this e-mail is a bit rough - I wanted to respond quickly before catching my plane.
 
Tony Rogers
tony.rogers@ca.com
-----Original Message-----
From: Katharine Jagger [mailto:KJAGGER@uk.ibm.com]
Sent: Mon 03-Nov-03 3:27
To: uddi-spec@lists.oasis-open.org
Cc:
Subject: RE: [uddi-spec] Groups - uddi-spec-tc-tn-understandingkeypartitions-20030602.doc uploaded





Tony

Thanks for your reply.

I did not misunderstand the definition of "partition" used in the TN - I
was pointing out that this definition is at odds with the definition of a
partition used in the spec.  You say "Perhaps another way of defining the
current key partition is as the set of all keys that can be derived from a
particular key generator", but this is again slightly different from
(though closer to) the definition of a partition given in the spec (section
5.2.2.1 "Key generator keys and their partitions".)  Surely the TN should
use terms in the same way as the spec, to avoid confusion?

I am very surprised by your suggestion that under certain circumstances it
is possible for a publisher to publish a derivedKey key generator when they
do not own the keyGenerator of the partition in which it lies!  This is
entirely contrary to the spec (section 5.2.2.1), which states "Only the
publisher associated with a particular partition is given the authority to
assign keys within the partition."


Regards,

Katharine Jagger.

-----------------------------------------------------------------------
Katharine Jagger - Software Engineer
Sun Certified Java Programmer
Web Services Development
MP 208, IBM Hursley
Time Zone: as London (currently GMT, EST+5, CST+6, MST+7, PST+8)
Office location A4133; Tie line:  7-245196
-----------------------------------------------------------------------



                                                                                                                                      
                      "Rogers, Tony"                                                                                                  
                      <Tony.Rogers@ca.c        To:       Katharine Jagger/UK/IBM@IBMGB, <uddi-spec@lists.oasis-open.org>              
                      om>                      cc:                                                                                    
                                               Subject:  RE: [uddi-spec] Groups -                                                     
                      01/11/2003 20:21          uddi-spec-tc-tn-understandingkeypartitions-20030602.doc uploaded                      
                                                                                                                                      
                                                                                                                                      




There's one slight misunderstanding I should comment upon. Contrary to your
reading, a key partition as defined in this context does include all of the
keys in the key partitions derived from it. To be honest, I prefer your
take on the matter, because it clarifies the question of whether the owner
of a "parent" partition can publish keys from a "child" partition (terms
used loosely, but I think comprehensibly) - the answer is NO, they cannot
publish a key from a child partition until they have published the key
generator for the child partition (said key generator belongs to the parent
partition, and so is a permissible publishing). So a child partition is a
proper subset of the parent partition, not disjoint from it, in the current
intent. Perhaps another way of defining the current key partition is as the
set of all keys that can be derived from a particular key generator, both
directly (keys which can be published by the owner of this key generator)
and indirectly (keys which can be published by the owners of key generators
derived directly and indirectly from this one).

The more I think about it, the more I like your interpretation :-) It will
require some rewriting of the technote (which we already planned, and for
which your notes will prove useful, thank you), and may have an impact upon
the language of the spec - I think we should look carefully at that.

There's a second small misunderstanding, too. The section that describes a
way to control keys is not prescriptive, but describes a formal way in
which keys might be controlled. It is possible that a registry may adopt a
looser, less formal, approach, in which case the Green division of the
Widget corporation may well be permitted to publish their own key generator
- in the less formal approach a publisher only requires an out-of-band
"permission" to publish a key generator (I don't like this, but it matches
how some implementations operate, I gather). Only when the publishing of
key generators is tightly controlled do we require the key to be published
by the owner of the partition in which it lies, and then transferred to the
publisher desiring it.

Thank you for your critical reading of the technote - a new set of eyes is
invaluable at this stage, and can help improve the document substantially.

Tony Rogers
tony.rogers@ca.com

-----Original Message-----
From: Katharine Jagger [mailto:KJAGGER@uk.ibm.com]
Sent: Fri 31-Oct-03 10:08
To: uddi-spec@lists.oasis-open.org
Cc:
Subject: Re: [uddi-spec] Groups -
uddi-spec-tc-tn-understandingkeypartitions-20030602.doc uploaded







      Hi

      I have studied the parts of the spec relating to uddi keys closely,
      and so
      I read with interest the draft Technical Note on Understanding Key
      Partitions.

      As someone who is reading the TN from the perspective of an
      implementer
      rather than a spec writer, I thought my comments may be of some use
      to you.

      As a starting point to understanding uddiKeys, I found the spec
      sections
      4.4.1 "Recommended syntax" and 4.4.2 "Examples of keys" an excellent
      introduction to what a uddiKey actually looks like and what the
      format of a
      valid uddiKey is.  May I suggest reproducing these sections in whole
      or in
      part at the beginning of the TN, so that, as section 1.2 "Background
      Material" of the TN states, a publisher does not have to read the
      specification first in order to understand the TN?

      Following on from understanding uddiKey formats to understanding
      their
      partitions, I found section 5.2.2.1 of the spec a clear, succinct
      description of partitions (I understand CR027 clarifies this further)
      that
      followed logically on from sections 4.4.1 and 4.4.2.  Could this be
      reproduced in place of the explanation in section 2.1 of the TN and
      the
      corresponding diagram, which I am afraid to say did not make any
      sense to
      me even though I am familiar with the spec sections on uddiKeys?


      Comments on Section 2.1.1 "Set Theory":

      Lines 120-124:
      The mathematical definition of a "partition" of a space X is a set of
      disjoint subsets of X such that their union is all of X.  The spec
      uses the
      word "partition" slightly differently (though acceptably), to mean a
      single
      one of these disjoint subsets of the whole key space.  Thus by
      definition
      one key partition cannot be a subset of another key partition.  Hence
      there
      are only two possible relationships between key partitions - they are
      the
      same, or they are disjoint.
      See section 5.2.2.1 of the spec for a definition of a key partition
      as
      "non-overlapping and hierarchically arranged."

      Line 123:  A proper subset S of a set A is in fact a subset of A such
      that
      there is at least one element of A that is not in S. (A set is wholly
      contained within itself but is not a proper subset of itself.)

      When illustrating the hierarchical nature of key partitions, may I
      suggest
      using an analogy of a directory structure instead of subsets?  A
      directory
      structure is something anyone reading the TN would be familiar with,
      though
      perhaps not everyone is familiar with set theory.  A directory (minus
      its
      contents) is then analagous to a keyGenerator, and files within that
      directory are analagous to keys with the partition of that
      keyGenerator.
      The immediate contents of the directory then make up the key
      partition.  A
      directory itself is a member of the directory above it in the
      hierarchy, in
      the same way as a keyGenerator belongs to the partition of the
      keyGenerator
      above it in the hierarchy.


      Comments on Section 2.1.2 - "In Terms of String Matching"

      Lines 137-140:
      The colon is in the wrong place - it should read: "Every key of the
      form
      A:x, for any non-empty string x that is not the string
      "keyGenerator", lies
      in the key partition of A:keyGenerator."  However this is in any case
      rendered incorrect when the definition of a key partition is
      corrected to
      exclude keys in a sub-partition.

      Lines 141-143 are also incorrect in that they allow the key
      "uddi:tempuri.com:exampletwo" to be in the partition
      "uddi:tempuri.com:example:keyGenerator" (replacing "A" with
      "uddi:tempuri.com:example" and "B" with "two").

      Line 144 - I have not seen anywhere in the spec that the key
      "uddi.tempuri.com:example:keygeneratorthatisnotreallyakeygenerator"
      is
      disallowed.


      Comments on Example 2.4.1

      Lines 234-237:  Green division cannot publish this tModel.  Widgets
      Inc
      must publish it and then transfer it to Green division.


      Comments on Section 2.2.3 "A way to control keys using the UDDI APIs"

      As I understand it there is a clear registry policy point "Registry
      Key
      Generation" that states "The registry defines a policy for whether
      and how
      a given node or publisher is allowed to register a key generator
      tModel."
      Thus, in the same way that the registry must decide by policy who may
      publish data in the registry, it must decide by policy which of these
      publishers are allowed to publish key generators, and domainKey key
      generators.

      As suggested in the TN, one possible way this policy may be
      implemented
      would be to decide that only an "administrator publisher" can publish
      domainKey key generators, and these are then transferred to
      individual
      publishers.  However, this seems to introduce an extra layer of
      administrative overhead, in that presumably a publisher must first
      register
      with the registry, and then subsequently must ask the administrator
      (out-of-band) to publish a key generator and transfer it to them.

      A simpler way to implement this policy would be to let the registry
      (or
      administrator) decide at the time of the user's registration whether
      or not
      they may publish domainKey key generators.  This would reduce the
      administative steps required from two to one, and once a publisher
      had
      registered they would be able to publish a domainKey key generator
      straightaway.

      Of course, the point of having certain things left to registry policy
      is
      that the implementation of a particular policy is a matter of choice.
      Which (if any) of the above two approaches is chosen is a matter of
      policy
      - the TN seems to be mandating which should be chosen and this does
      not
      leave any choice.


      Regards,

      Katharine Jagger.

      -----------------------------------------------------------------------

      Katharine Jagger - Software Engineer
      Sun Certified Java Programmer
      Web Services Development
      MP 208, IBM Hursley
      Time Zone: as London (currently GMT, EST+5, CST+6, MST+7, PST+8)
      Office location A4133; Tie line:  7-245196
      -----------------------------------------------------------------------





                            bellwood@us.ibm.c

                            om                       To:
      uddi-spec@lists.oasis-open.org

                                                     cc:

                            31/10/2003 14:21         Subject:  [uddi-spec]
      Groups - uddi-spec-tc-tn-understandingkeypartitions-20030602.doc
                                                      uploaded







      The document uddi-spec-tc-tn-understandingkeypartitions-20030602.doc
      has
      been submitted by Tom Bellwood (bellwood@us.ibm.com) to the OASIS
      UDDI
      Specification TC document repository.

      Document Description:
      Key Partitions TN Updates from 11/03 FTF

      Download Document:
      http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/4076/uddi-spec-tc-tn-understandingkeypartitions-20030602.doc



      View Document Details:
      http://www.oasis-open.org/apps/org/workgroup/uddi-spec/document.php?document_id=4076




      PLEASE NOTE:  If the above links do not work for you, your email
      application
      may be breaking the link into two pieces.  You may be able to copy
      and
      paste
      the entire link address into the address field of your web browser.



      To unsubscribe from this mailing list (and be removed from the roster
      of
      the OASIS TC), go to
      http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php

      .





      To unsubscribe from this mailing list (and be removed from the roster
      of the OASIS TC), go to
      http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php
      .





To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]