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] | [Elist Home]


Subject: RE: [uddi-spec] Change request for handling of keys in V3



Ugo,

My proposal is to essentialy limit the treatment of all keys in UDDI V3 so they are case folded prior to processing an API (or generating/verifying a signature).  The proposal is then, not limited to the UDDI scheme that is recommended in the specification.

In the event that someone wanted to use another scheme in conjunction with UDDI V3, it would be treated similarly as case folded.  This could conflict with particular URI schemes concept of equivalence and case, but I'm recommending the tradeoff for reasons of implementation, testing and interoperability.  While there may be theoretical cases for using other schemes as the keys for UDDI entities, the UDDI scheme for keys includes the concepts of DNS and UUID, both of which are case insensitive, and prior to this change request would be persisted as case sensitive for persistence across the registry.

As far as supporting any kind of URI scheme for the primary keys in UDDI, I would support this when a scheme for general canonicalization of anyURI  that accounts for URI schemes is standardized.


Andrew Hately
IBM Software Solutions and Strategy
UDDI Development, http://uddi.ibm.com/

Email: hately@us.ibm.com



Ugo Corda <UCorda@SeeBeyond.com>

11/06/2002 03:03 PM

       
        To:        Andrew Hately/Austin/IBM@IBMUS, uddi-spec@lists.oasis-open.org
        cc:        
        Subject:        RE: [uddi-spec] Change request for handling of keys in V3

       


Hi Andrew,
 
I read the document and I would like to better understand why the proposed solution does not face the same difficulties mentioned in SCC14N, Section 5.4, in relation to the canonicalization of anyURI (difficulties that convinced SCC14N to give up on the idea of canonicalizing anyURI). Here is what the SCC14N spec says:
 
"... it is reasonable to ask whether a canonical lexical representation for data of type anyURI should be specified. This, however, is a difficult if not insurmountable task. Many of the details of an appropriate canonicalization (such as case-mapping or case-folding) are inherently scheme-specific, and it is intrinsically impossible for any one Schema Centric Canonicalization implementation to understand the universe of possible URI schemes it might encounter (and so canonicalize them all appropriately). Even for some commonly known URI schemes, the relevant specifications lack crisp clarity on some germane issues. And the algorithm of §5.2 of RFC2396 can (see ibid, §5.1) only be carried out in the context of a specific base URI; as generally speaking such relevant base URI may be application-level notions not represented in XML, the algorithm of §5.2 must remain out of scope so far as XML canonicalization is concerned."
 
Is the fact that your proposal is limited to the "uddi" URI scheme sufficient to eliminate all the difficulties mentioned above?
 
Thank you,
Ugo

 
-----Original Message-----
From:
Andrew Hately [mailto:hately@us.ibm.com]
Sent:
Wednesday, November 06, 2002 9:51 AM
To:
uddi-spec@lists.oasis-open.org
Subject:
[uddi-spec] Change request for handling of keys in V3


Luc and Tom,


Please accept this attached change request for the UDDI V3 specification.


I would like to have discussion of this item added to the agenda for next weeks meeting.


Thanks.





Andrew Hately
IBM Software Solutions and Strategy
UDDI Development, http://uddi.ibm.com/

Email: hately@us.ibm.com




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


Powered by eList eXpress LLC