Re: RetrievalMethod

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].

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 Thursday, 17 August 2000 10:18:39 UTC