RE: [uddi-spec] ASN.1 notation as an alternative to XML Schema proposal

[GARG Shishir / FTR&D / US <shishir.garg@rd.francetelecom.com>]

Title: RE: [uddi-spec] ASN.1 notation as an alternative to XML Schema proposal

To start with, Claus' and Bob's concerns are duly noted. We discussed
some of these issues and preliminary feedback is as follows:

* First, the isomorphic ASN.1-encoded-XML and XML-Schema is not completely done. As I understand it, they are very close to it, but are not completely there yet. This is done via "Extended-XER (XML Encoding Rules)"

> > Shishir: Not that I’ve looked (sorry), but it is even the
> case that all
> > UDDI v2 XML instances which are valid according to the UDDI v2 XML
> > Schema definitions are in fact valid according to the XML
> Encoding Rules
> > (Basic or otherwise) of the sample ASN.1 schemas for UDDI
> v2 that you
> > provided? That is can we take reliably data produced
> according to the
> > XML Schema mechanism and validate it according the ASN.1-derived
> > mechanism? Can we reliably do it the other way around?
> >

Reliable two-way translation support for XML-Schema and ASN.1 exists, but I don't think it covers Cannonical XML, Exclusive Canonical XML or Schema Centric Canonicalization, for that matter.

Since Canonicalization is a basic requirement for XML-DSig I agree that this will be a concern and needs to be addressed, but a lot more work is needed.

May I ask, primarily out of ignorance, why the Schema Centric Canonicalization is a UDDI V3 spec, rather than a more widely accepted spec?

> Garg's writeup seems to imply that the major reason is to
> make UDDI more
> acceptable in low-bandwidth environment (meaning mobile
> communication?).
> Garg, is that the primary motivation / requirement? Could you
> elaborate
> on it?

Thanks Sam for raising this. I think there are the following primary motivations here:

* ASN.1 is used widely: X.400, X.500, CMIP and SNMP, EDI's ODIF, etc.

* The widely accepted nature of ASN.1 and the emergence of XML has led to a lot of interest in attempting to make the two compatible

* Considering that ASN.1 Encoding is usually binary and results in a much more compact format, we believe that compatibility of emerging WS standards with ASN.1 encoding schemes (essential backward compatibility with existing systems) will be critical to rapid adoption of these technologies among telecommunication companies like ours.

Olivier, Rajul, etc., please feel free to add to this list.

As of now, the ASN.1 group has ruled out the option of defining a canonical EXTENDED-XER. Therefore, we need to assess the importance of this within this group and decide on the right course of action.

Apologies for the late message, I was sick and away from work for a good part of last week. But I'm much better now, thanks!

-Shishir.

> -----Original Message-----
> From: Wai-Kwong Sam LEE [mailto:Sam.Lee@oracle.com]
> Sent: Thursday, March 06, 2003 4:08 PM
> To: Bob Atkinson
> Cc: Von Riegen, Claus; GARG Shishir / FTR&D / US;
> uddi-spec@lists.oasis-open.org
> Subject: Re: [uddi-spec] ASN.1 notation as an alternative to
> XML Schema
> proposal
>
>
> While Claus and Bob pointed out the technical difficulties of
> adopting
> ASN.1 that we should all consider, at a higher level, I think it'd be
> helpful for Garg and other ASN.1 experts to explain /
> elaborate on the
> motivation of using ASN.1 as opposed to XML, before jumping into the
> technical details of the ASN.1.
>
> Garg's writeup seems to imply that the major reason is to
> make UDDI more
> acceptable in low-bandwidth environment (meaning mobile
> communication?).
> Garg, is that the primary motivation / requirement? Could you
> elaborate
> on it?
>
> After we evaluate the motivation and the requirements, if
> requirements
> are important enough, I think we may still adopt the
> requirements; and
> we can then discuss the solution. Garg proposes a solution which can
> serve as a starting point.
>
>
> - sam
>
> Bob Atkinson wrote:
> > I concur with Claus’ well-put thoughts.
> >
> > 
> >
> > The task of dealing with the signatures that Claus mentions
> is not a
> > small one. The heavy lifting of the design work of V3 in
> this respect
> > was coming up with an appropriate canonicalization algorithm for
> > XML-schema-specified XML (in the ASN.1 world this is in
> analogy to the
> > specification of the Distinguished (binary) Encoding Rules
> as opposed to
> > the Basic Encoding Rules). This algorithm is hand-in-glove
> intimate with
> > the expressivity of XML-schema (as were the DER with respect to the
> > expressivity of BER). Unless XML Schema and XML-encoded-ASN.1 were
> > entirely isomorphic (which would astound me, but I admit I
> do not know
> > for certain that they are not), then defining ASN.1
> equivalents of the
> > UDDI v3 XML schemas than when XML Encoded and canonicalized by
> > ASN.1-derivied algorithms manages to preserve the signature
> will be a
> > Herculean task.
> >
> > 
> >
> > Shishir: Not that I’ve looked (sorry), but it is even the
> case that all
> > UDDI v2 XML instances which are valid according to the UDDI v2 XML
> > Schema definitions are in fact valid according to the XML
> Encoding Rules
> > (Basic or otherwise) of the sample ASN.1 schemas for UDDI
> v2 that you
> > provided? That is can we take reliably data produced
> according to the
> > XML Schema mechanism and validate it according the ASN.1-derived
> > mechanism? Can we reliably do it the other way around?
> >
> > 
> >
> > Thanks.
> >
> > 
> >
> >                 Bob
> >
> > 
> >
> >
> --------------------------------------------------------------
> ----------
> >
> > *From:* Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> > *Sent:* Wednesday, March 05, 2003 1:19 AM
> > *To:* 'GARG Shishir / FTR&D / US'; 'uddi-spec@lists.oasis-open.org'
> >
> > 
> >
> > Shishir,
> >
> > 
> >
> > Thanks for the details on ASN.1.
> >
> > 
> >
> > However, adding a notation alternative to XML Schema and a protocol
> > alternative to SOAP/HTTP to the set of UDDI Version 2
> specifications at
> > this point in time seems not to be appropriate to me. There
> are other
> > schema notations, such as RELAX NG, and other protocols,
> such as HTTP
> > w/o SOAP, we could also consider, but we always limited our
> scope to the
> > most common ones so far.
> >
> > 
> >
> > I'm not saying that it is not useful to propose alternatives, but
> > since alternative schema notations and protocols should note change
> > UDDI's core, I'd rather like to see them added layered on
> top of the
> > UDDI specifications, for example, by starting with a technical note.
> >
> > 
> >
> > Also, since we are also in the process to finalize UDDI
> Version 3, any
> > alternatives should also work with this version. The issue with the
> > mapping of W3C XML Digital Signatures to ASN.1 that came up
> yesterday
> > should be one of the first items to be resolved in a Technical Note.
> >
> > 
> >
> > Regards,
> >
> >  Claus
> >
> > 
> >
> > -----Original Message-----
> > *From:* GARG Shishir / FTR&D / US
> > [mailto:shishir.garg@rd.francetelecom.com]
> > *Sent:* Mittwoch, 5. März 2003 02:55
> > *To:* 'uddi-spec@lists.oasis-open.org'
> > *Cc:* DUBUISSON Olivier FTRD/DTL/LAN; 'Rajul Gupta'; 'Paul Thorpe';
> > 'Bancroft Scott'; 'Alexandru Czimbor'; CAHUZAC Maud / FTR&D / US
> > *Subject:* [uddi-spec] ASN.1 notation as an alternative to
> XML Schema
> > proposal
> >
> > Hello folks,
> >
> > As discussed briefly on today's call, here are the initial
> documents to
> > get the discussion going. The doc file contains a
> description of what is
> > in this proposal, along with a few examples to make the case clear.
> >
> > We are not necessarily aiming to make it to the V2
> specification (since
> > it was just sent to the OASIS board for review), but we are
> not sure if
> > it should just become a Technical Note and be left at that.
> >
> > Lets look for all the feedback we can get on this proposal.
> >
> > Regards,
> > Shishir GARG.
> > France Telecom R&D
> > 650.875.1540
> > shishir.garg@rd.francetelecom.com
> >
> > Attached: Overview doc + UDDI V2 converted schemas
> >
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>