- From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
- Date: Fri, 18 Aug 2000 15:43:37 -0400
- To: merlin <merlin@baltimore.ie>
- cc: w3c-ietf-xmldsig@w3.org
The consensus of those on the conference call yesterday was to try to re-use as much exiting mechanism as possible. So what we came up with was <RetrievalMethod URI="...", Type="*1"> (Transforms)? </RetrievalMethod> that is, the syntax is the same as Reference. *1 values for Type would be as in 4.3.3 except that in the "http://www.w3.org/2000/07/xmldsig#*2", *2 would be an element from KeyInfo other than RetrievalMethod. See other comment below. Thanks, Donald From: merlin <merlin@baltimore.ie> Message-Id: <200008171417.PAA12758@cougar.baltimore.ie> To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com> Cc: w3c-ietf-xmldsig@w3.org In-reply-to: <200008171340.JAA15971@torque.pothole.com> Date: Thu, 17 Aug 2000 15:17:42 +0100 >Hi, > >I actually think that such a structure is slightly limiting; >it cannot represent an HTTP POST location; e.g., [1]. I >personally prefer either no defined internal structure >(completely flexible) or [0]. If the inability to do an HTTP POST is a problem here, which I'm not sure it is in a practical sense, then wouldn't we need to generalize Reference also? And no internal structure menas giving up on interoperability. >Merlin > >[0] > ><RetrievalMethod Type='URI'> > <Location URI='URI'> * </Location> > <Encoding Algorithm='URI'> * </Encoding> ></RetrievalMethod> > >[1] > ><RetrievalMethod> > <Location URI='URI'><HTTP Method='POST'>post-data</HTTP></Location> ></RetrievalMethod> > >r/dee3@torque.pothole.com/2000.08.17/09:40:17 >> >>I don't recall there being any discussion of Merlin's comments on >>RetrievalMethod below. The main change suggested is to drop the >>Method element as it is inherent in the Location URI. Also, as far as >>I know, we have decided to make fields which are always URIs be >>attributes and have algorithms be elements with an Algorithm >>attribute... This leads to the following as the most consistent with >>the rest of our syntax: >> >><RetrievalMethod Location="http://..." Type="foo#x509-certificate"> >> <Encoding Algorithm="bar#base64"> >> <possible-encoding-parameter>...</p.-e.-p.> >> </Encoding> >></RetrievalMethod> >> >>On the other hand, the minimum change would be to simply amend the >>current definition by dropping the Method element. >> >>How much implementation is there of RetrievalMethod at this point? >>I.E., how much pain is involved in the larger change? >> >>Thanks, >>Donald >> >>>At 07:44 PM 7/19/2000 +0100, merlin wrote: >>> > >>> >r/dee3@torque.pothole.com/2000.07.19/13:40:29 >>> > >>> >>Making some of this stuff optional seems reasonable but I would think >>> >>that a lot of implementations would just pass off the uri to some >>> >>retrieval mechanism without looking inside it and still want a >>> >>separate indication of type and encoding. >>> > >>> >>Donald >>> > >>> >I agree. I just don't grasp the reason for the current >>> >structure of the element. >>> > >>> >It seems to me that a minimal specification would be [1]: >>> > >>> > <RetrievalMethod Location="http://..." >>> > Type="foo#x509-certificate" Encoding="bar#base64" /> >>> > >>> >A more pedantic specification would be [2]: >>> > >>> > <RetrievalMethod Type="foo#x509-certificate> >>> > <Location>http://...</Location> >>> > <Encoding Algorithm="bar#base64" /> >>> > </RetrievalMethod> >>> > >>> >Type could be expanded into an element, if desired. >>> > >>> >However, I can't see how Type would be more than a URI, >>> >nor do I see the impact of Encoding on Type, as captured >>> >in the current spec: >>> > >>> > <RetrievalMethod> >>> > <Location>http://...</Location> >>> > <Method><x:From-ASN1-To-Key-Info-Foo /></Method> >>> > <Type Encoding="bar#base64"><x:Its-A-X509-Certificate-Foo /></Type> >>> > </RetrievalMethod> >>> > >>> >As I say, I just don't fully understand what would be a default >>> >implementation of the current element specification. >>> > >>> >Merlin >>> > >>> >[1] >>> > >>> ><element name='RetrievalMethod'> >>> > <complexType content='mixed'> >>> > <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/> >>> > </complexType> >>> > <attribute name='Location' type='uriReference' use='required'> >>> > <attribute name='Type' type='uriReference' use='optional'/> >>> > <attribute name='Encoding' type='uriReference' use='optional'> >>> ></element> >>> > >>> >[2] >>> > >>> ><element name='RetrievalMethod'> >>> > <complexType content='elementOnly'> >>> > <sequence minOccurs='1' maxOccurs='1'> >>> > <element name='Location' type='uriReference' minOccurs='1' >>>maxOccurs='1'/> >>> > <element ref='ds:Encoding' minOccurs='0' maxOccurs='unbounded'/> >>> > </sequence> >>> > <attribute name='Type' type='uriReference' use='optional'/> >>> > </complexType> >>> ></element> >>> > >>> ><element name='Encoding'> >>> > <complexType content='mixed'> >>> > <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/> >>> > <attribute name='Algorithm' type='uriReference' use='required'/> >>> > </complexType> >>> ></element> >>> > >>> >>From: merlin <merlin@baltimore.ie> >>> >>Message-Id: <200007182220.XAA10671@bobcat.baltimore.ie> >>> >>To: "Joseph M. Reagle Jr." <reagle@w3.org> >>> >>Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org> >>> >>In-reply-to: <3.0.5.32.20000718162839.00ad5e70@localhost> >>> >>Date: Tue, 18 Jul 2000 23:20:57 +0100 >>> >> >>> >>>r/reagle@w3.org/2000.07.18/16:28:39 >>> >>>>At 19:30 7/18/00 +0100, Merlin Hughes wrote: >>> >>>> >The Schema has mandatory content for the Type element. This >>> >>>> >seems wrong because it can't then be implemented interoperably >>> >>>> >without further specification. >>> >>>> >>> >>>>Are you suggestion it be change to optional? >>> >>>> >>> >>>> <element name='Type'> >>> >>>> <complexType content='mixed'> >>> >>>> <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/> >>> >>>> ... >>> >>> >>> >>>Something of that nature. RetrievalMethod simply seems >>> >>>underspecified given that it "SHOULD" be implemented. >>> >>>By making some of those parts optional, it could be >>> >>>read as minimally and sufficiently specified. >>> >>> >>> >>>For example, it seems reasonable to present a RetrievalMethod >>> >>>with the Location: >>> >>> >>> >>> ldap://ldap.baltimore.ie/CN=merlin?userCertificate;binary >>> >>> >>> >>>What, in this case, do I specify as the Method and Type, >>> >>>both of which are currently mandatory? >>> >>> >>> >>>By making Method and Type optional I can, at the very least, >>> >>>assume that the recipient will determine the type of key >>> >>>information from the URI. >>> >>> >>> >>>Merlin >>> >>> >>> >> >>> > >>> >>>_________________________________________________________ >>>Joseph Reagle Jr. >>>W3C Policy Analyst mailto:reagle@w3.org >>>IETF/W3C XML-Signature Co-Chair http://www.w3.org/People/Reagle/ >> >>------- End of Forwarded Message >>
Received on Friday, 18 August 2000 15:41:01 UTC