[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xcbf] SignedData Attributes - DigitalSignature Attributes
Alessandro, I detest attributes myself, and welcome John's suggested solution. When I see groups trying to come up with hard and fast rules and conventions for attribute versus element use I have to shake my head and smile. Little value that I can see in attributes in general, and an incredible amount of flux associated with their use. Phil Alessandro Triglia wrote: > >>-----Original Message----- >>From: Phil Griffin [mailto:phil.griffin@asn-1.com] >>Sent: Monday, August 12, 2002 19:34 >>To: Alessandro Triglia >>Cc: j.larmouth@salford.ac.uk; 'xcbf' >>Subject: Re: [xcbf] SignedData Attributes - DigitalSignature >>Attributes >> >> >> >> >>Alessandro Triglia wrote: >> >> >>>>-----Original Message----- >>>>From: Phil Griffin [mailto:phil.griffin@asn-1.com] >>>>Sent: Monday, August 12, 2002 17:37 >>>>To: j.larmouth@salford.ac.uk >>>>Cc: xcbf >>>>Subject: Re: [xcbf] SignedData Attributes - DigitalSignature >>>>Attributes >>>> >>>> >>>>Then it appears that XER is not sufficient here. >>>> >>>>It should be possible to send meta data in the >>>>communication, >>>> >>>> >>> >>>Is is certainly possible to send metadata in the communication. >>> >>>However, relying on the value of a data item (an attribute) >>> >>to determine >> >>>the XER encoding of another data item of the same data >>> >>structure is a >> >>>different thing, and was avoided. If you think about it, this would >>>require a decoder to examine the value of an attribute before it was >>>able to complete the decoding of another data item. Such a >>> >>dependence >> >>>is not desirable. >>> >> >>This may be a problem with the design of some >>tools, but using attributes on markup tags to >>describe the characteristics of the content >>that the tags encapsulate is common practice. >> >>Given >> >> Examp ::= SEQUENCE { >> this BOOLEAN, >> that BIT STRING >> } >> >>It is easy enough to specify an instance of type >>Example using XML markup as >> >> <Examp format='base64'> D234592FF0F </Examp> >> >>This encoding is processed from left to right, so >>the attribute indicating the formatting of the >>value of type Examp is seen by a tool when the >>tool examines the 'Tag', the character string >>"<Examp format='base64'>", which is before it >>encounters the actual value. >> >>Whether this is desirable or not, this is common >>practice for XML markup when using such as the >>language attribute, xml:lang='it', for example. >> > > > Phil, this was exactly my point. Using an attribute for describing some > property of the element content is indeed reasonable and is common > practice, I agree. Your example of "xml:lang" shows that. In this > case, the *application* receives the data (the text string in some > natural language), and can process it according to the language > indicated in the attribute. > > Using an attribute to tell the *decoder* how to decode a data item is an > entirely different thing. If a "format" attribute were used to carry > encoding information, the "format" attribute itself would not be part of > the abstract value, and the relationship between the XML document and > its infoset, and between the infoset and the abstract value, would > become less clean. > > The situation becomes still more complex and confused in your last > example, where you use two attributes, one carrying information about > the *encoding* of the other. There is no formal mechanism in XML 1.0 > and in any schema language that can link two attributes in this way. > Please notice that the order of attributes is arbitrary and not > significant in XML, so your consideration about left-to-right processing > does not apply to this case. But again, linking two attributes in this > manner is perfectly legal and I understand it may be common practice *if > the link is defined at the application level* rather than at the > encoding/decoding level. > > Alessandro > > > >>It is not even unreasonable to expect the likes >>in XML of >> >> <Examp format='base64' value='D234592FF0F'/> >> >>Phil >> >> >> >> >>>Attributes in XER are just components of a SEQUENCE that >>> >>happen to be >> >>>encoded as XML attributes rather than as child elements. >>> >>In (vanilla) >> >>>XER and in CXER, the same components are always encoded as child >>>elements, never as attributes. >>> >>> >>> >>> >>>>as how would both sides know if >>>>'011000' were a three octet string or a six bit >>>>binary value. This is what attributes are used >>>>for in XML. >>>> >>>> >>> >>>I disagree. There is no such capability in RELAX NG and XML >>> >>Schema **at >> >>>the encoding/decoding level**. >>> >>>You can clearly include metadata in an ASN.1 schema, but >>> >>that would be >> >>>information about the data, not information about how the >>> >>data is to be >> >>>encoded/decoded by the XER encoder/decoder. You can do what you >>>describe above by defining the component as a UTF8String >>> >>and having the >> >>>application deal with the value. The question is why? >>> >>>Alessandro >>> >>> >>> >>> >>> >>>>I did not seek to disallow a BIT STRING signature >>>> >>>>from being carried or displayed as bits when I >>> >>>>proposed that it also be allowed to carry this >>>>information as octets. >>>> >>>>And I would not wish to prohibit an application >>>> >>>>from carrying a certificate signed as an XML >>> >>>>encoding as XML instead of as a base64 encoding. >>>> >>>>Phil >>>> >>>> >>>> >>>> >>>>John Larmouth wrote: >>>> >>>> >>>> >>>>>The "format=" is not current XER. >>>>> >>>>>This needs thinking through a bit more, Phil. >>>>> >>>>>We certainly intend to allow BASE64 encodings, but currently the >>>>>specification that it is BASE64 will be part of the encoding >>>>>instructions (known to both sides), and not something which >>>>> >>>>> >>>>is carried >>>> >>>> >>>>>in an instance of communication. >>>>> >>>>>So I guess I oppose your "format=" parameter. >>>>> >>>>>Why do you need to have that transmitted in the XML? >>>>> >>>>>John L >>>>> >>>>> >>>>>Phil Griffin wrote: >>>>> >>>>> >>>>> >>>>>>I proposed on 8/6 that the following XML markup be used >>>>>>in XCBF. >>>>>> >>>>>> <version> ........................ </version> >>>>>> <digestAlgorithms> ............... </digestAlgorithms> >>>>>> <encapContentInfo> ............... </encapContentInfo> >>>>>> <certificates format='base64'> ... </certificates> >>>>>> <crls format='base64'> ........... </crls> >>>>>> <signerInfos> .................... </signerInfos> >>>>>> >>>>>>The signature component of the SIGNATURE parameterized >>>>>>type identifies a value of type BIT STRING. These bits >>>>>>are not used as bit flags, and signatures tend to be in >>>>>>the thousands of bits in length and can more easily and >>>>>>compactly be represented as OCTET STRINGs. I propose that >>>>>>the following XML markup be used for these values: >>>>>> >>>>>> <signature format='hex'> ... </signature> >>>>>> >>>>>>So far, I have received no comments. Unless I hear comments >>>>>>that use of these attributes is unacceptable, I will include >>>>>>them in the next release of the XCBF document. >>>>>> >>>>>>Phil >>>>>> >>>>>>---------------------------------------------------------------- >>>>>>To subscribe or unsubscribe from this elist use the subscription >>>>>>manager: <http://lists.oasis-open.org/ob/adm.pl> >>>>>> >>>> >>>>---------------------------------------------------------------- >>>>To subscribe or unsubscribe from this elist use the subscription >>>>manager: <http://lists.oasis-open.org/ob/adm.pl> >>>> >>> >>>---------------------------------------------------------------- >>>To subscribe or unsubscribe from this elist use the subscription >>>manager: <http://lists.oasis-open.org/ob/adm.pl> >>> >> > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC