RE: Revised syntax proposal

Dave,

Comments follow...

> Richard Wrote:
> >
> > Not really. Adoption of a similar model requires the
> definition of an
> > intermediary element for algorithm parameters (counter-part of
> > attribute-data).
> >
> > <!ELEMENT signedAttributes (attributeData)+>
> > <!ELEMENT attributeData ANY>
> > <!ATTLIST attributeData
> >      type CDATA #REQUIRED
> > >
> >
> > <!ELEMENT c14nAlg (algParameter)*>
> > <!ATTLIST c14nAlg
> >     xml:link CDATA #FIXED 'simple'
> >     href     CDATA #REQUIRED
> > >
> > <!ELEMENT algParameter ANY>
> > <!ATTLIST algParameter
> >     type  CDATA #REQUIRED
> > >
>
> Dave Replied:
>
> This syntax looks fine to me.  If there's no objection (other than
> looking for consensus on whether href is the right way to point to
> things), we can use it for all the alg types.
>

Fine, if we agree on a common model for attribute and algorithm. However, I
think that we can do without the second level that only provides for typing
of the element value. Unless, attribute values and algorithm parameters make
use of common data types (Date, Integer, String...), the tagname of the
attribute or parameter could serve the same purpose.

EXAMPLE WHERE THERE IS NO BENEFIT
---------------------------------

<dsig:signedAttributes>
  <dsig:attributeData type='http://w3.org/xmldsig/signing_time'>
    <dsig:signingTime>1999-08-16T12:14:06.031-0500</dsig:signingTime>
  </dsig:attributeData>
</dsig:signedAttributes>

In this example, dsig:signingTime and the type attribute on the
attributeData element are redundant.

EXAMPLE WHERE THERE IS NO BENEFIT
---------------------------------

<dsig:signedAttributes>
  <dsig:attributeData type='http://w3.org/xmldsig/signing_time'>
    <dcd:date>1999-08-16T12:14:06.031-0500</dcd:date>
  </dsig:attributeData>
</dsig:signedAttributes>

Notice that this example makes use of a "dcd:date", assuming that dcd is
associated to a generic DTD for common data types.

EXAMPLE WHITHOUT INTERMEDIARY LEVEL
-----------------------------------

<dsig:signedAttributes>
  <dsig:signingTime>1999-08-16T12:14:06.031-0500</dsig:signingTime>
</dsig:signedAttributes>

The attribute type is provided implicitly by the tag name of the element
(e.g. dsig:signingTime). Unless there is (or will be) a DTD for common data
types, this is the syntax that I prefer.

> > >
> > > Richard D. Brown Wrote:
> > >
> > > 10.1- I suggest that you provide an encoding attribute.
> > > Also, we could have share the same definition between content,
> > > sigValue, digestValue...
> > >
> > > David Solo Responded:
> > >
> > > Why do you think we need flexibility in encoding?  I had
> hoped that we
> > > could define a single encoding for all our top level items.
> > >
> >   Richard Wrote:
> >
> > Agreed that we can limit encoding to base64. But we still have to
> > distinguish between encoded and non-encoded content.
>
> David Replied:
>
> Where do you think this is an issue (if it refers to the
> signed object,
> then I think the encoding info belongs in the definition of the
> encapsulated type, not in signature)?
>
The issue is mostly for the content element that is used to package the
object value within the signature block. You probably have to distinguish
between an embedded XML element (no-encoding) and a base64 encoded binary
object.

Sincerely,

Richard D. Brown

Received on Monday, 16 August 1999 13:27:13 UTC