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: CR080 - discard_transferToken behaviour



Hi

I have a question relating to spec CR 080 on discard_transferToken behaviour.

My question is, what error (if any) should be returned if one of the keys passed to discard_transferToken is owned by the publisher but the transferToken corresponding to the key is owned by another publisher?

This situation can occur when:

1.  Publisher 1 publishes a business with key uddi:mycompany.com:key1.
2.  Publisher 1 obtains a transferToken for the business.
3.  Publisher 1 deletes the business.
4.  Publisher 1 transfers custody of the keyGenerator tModel uddi:mycompany.com:keygenerator to Publisher 2.
5.  Publisher 2 publishes a business with key uddi:mycompany.com:key1.
6.  Publisher 2 attempts to get a transferToken for the business, but is refused because a transferToken already exists (owned by Publisher 1).
7.  Publisher 2 attempts to discard the existing transferToken associated with uddi:mycompany.com:key1.

The possible outcomes I see for step 7 are:

A.  Publisher 2 is allowed to discard a transferToken belonging to another publisher, because it covers one of their own keys.
B.  E_userMismatch is returned because the publisher does not own the transferToken.  (This may be confusing because if the error message contains the key that caused the error, the publisher may think this means that they don't own the key, which of course they do.)
C.  The transferToken is not discarded and no error is returned.
D.  The problem is actually with step 6.  Publisher 1 should be allowed to obtain a transferToken because although one exists, it is not theirs.  What should then happen to the existing transferToken?
E.  The problem is actually with step 3.  When an entity is deleted that is covered by an existing transferToken, any associated transferToken should also be deleted.  (Presumably this would apply to businesses only, because it would still make sense to transfer custody of a "deleted" tModel.)  This would make sense because as soon as an entity is deleted, the transferToken associated with it becomes unusable anyway, because an attempt to use the transferToken would result in E_invalidKeyPassed due to the deleted key.

Note that if Publisher 2 is not allowed to discard the existing transferToken (outcomes B and C) then this presents a problem because Publisher 1 cannot discard the transferToken either.  If Publisher 1 calls discard_transferToken, passing a keyBag containing the key uddi:mycompany.com:key1, they will get E_userMismatch because they do not own the key.

This leads to another question:  if Publisher 1 calls discard_transferToken by passing the transferToken rather than a keyBag, or by passing a keyBag which includes other keys covered by the transferToken but does not include the key uddi:mycompany.com:key1, do they get E_userMismatch because the transferToken covers a key which is not owned by them, even though it was not included in the discard_transferToken call?  Or does the call succeed regardless?

I would very much welcome your comments.

Many thanks,

Katharine Jagger.

-----------------------------------------------------------------------
Katharine Jagger - Software Engineer
Sun Certified Java Programmer
Web Services Development
MP 208, IBM Hursley
Office location A4133; Tie line:  7-245196
-----------------------------------------------------------------------
Save paper - save orangutans!
Please send me information electronically rather than on paper - many thanks!


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