W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

Re: RetrievalMethod

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Fri, 18 Aug 2000 15:43:37 -0400
Message-Id: <200008181943.PAA18232@torque.pothole.com>
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 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:10 GMT