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.
|