Re: [dss] Core protocol: is the <Status> element the status of what has been validated ?

[Trevor Perrin <trevp@trevp.net>]

At 01:09 PM 10/22/2003 +0200, Juan Carlos Cruellas Ibarz wrote:
> >> [....]
> >><xs:simpleType name="ResultValueType">
> >>         <xs:restriction base="xs:string">
> >>                 <xs:enumeration value="Success"/>
> >>                 <xs:enumeration value="Failure"/>
> >>                 <xs:enumeration value="Refused"/>
> >>         </xs:restriction>
> >></xs:simpleType>
> >>
> >><xs:simpleType name="CodeErrorType">
> >>         <xs:restriction base="xs:string">
> >>                 <xs:enumeration value="InternalError"/>
> >>                 <xs:enumeration value="UntrustedToken"/>
> >>                 <xs:enumeration value="UnrecognizedToken"/>
> >>                 <xs:enumeration value="UserNoAuthorized"/>
> >>                 <xs:enumeration value="Request error"/>
> >>         </xs:restriction>
> >></xs:simpleType>
> >>
>
>Do you agree in that these situations deserve some coding?

Yes.  I'm sure there's other cases we need to cover too.



> >I still kinda like re-using the <Status> to say whether the signature
> >succeeded or failed.  It just gives a nice symmetry to things.  Both the
> >Sign and Request protocols send <Options> and receive <Status> and
> ><Outputs>, and the only difference is that the sign protocol receives a
> ><Signature>, and the verify protocol sends one:
>
>I would not call that re-using, but enlarging its semantics. IF you
>still see Status as an element without inner structure, ie, one
>whose value is a QName from a repertory I think that we are mixing two
>different

The <Status> I'm considering has <StatusCode> and <StatusMessage> children.


>meanings.....For me re-using is to take a previously defined element and
>using it as part of a new structure keeping its semantics...
>
>I do not like very much tags that seem to say something and in fact contain
>two types of information.
>Generally speaking, when somebody mentions "status" in a verification process
>I always think in the status of a certificate or whether the signature is
>valid or not,
>unless the "status" is followed by something like "the server has reached".
>
>So, I contend that we should clearly separate both issues, in different
>elements:
>
>1. Whether the server could process the request of the client.
>2. Whether the server found valid or unvalid the signature.
>
>Because they are denoting completely different things and in consequence
>they can fire in the client's side completely different actions!!!

They're different, but....related.  If the signature succeeds or fails to 
verify, then it's implied that the server could process the request.  So we 
can communicate both things within the single field.

This bothers you..  I kinda like it, though.  I guess it's just a matter of 
taste.



>I propose you the following:
>
><xs:element name="SignResponse">
>          <xs:complexType>
>                  <xs:sequence>
>                          <xs:element ref="dss:Result"/>
>                          <xs:element ref="dss:Signature" minOccurs="0"/>
>                          <xs:element ref="dss:Outputs" minOccurs="0"/>
>                  </xs:sequence>
>          </xs:complexType>
></xs:element>
>
><xs:element name="VerifyResponse">
>          <xs:complexType>
>                  <xs:sequence>
>                          <xs:element ref="dss:Result"/>
>                          <xs:element ref="dss:Outputs" minOccurs="0"/>
>                  </xs:sequence>
>          </xs:complexType>
></xs:element>
>
>
>And then define a Result having two different elements:
><xs:element name="Result" type="ResultType"/>
><xs:complexType name="ResultType">
>         <xs:sequence>
>                 <xs:element ref="ServerProcessingResult">
>                 <xs:element ref="Status" minOccurs="0">
>         <xs:sequence/>
></xs:complexType>
>
>---> I am using named types just because I remember better the
>syntax...
>
>Now, both elements would have a different repertory of predefined values, the
>symmetry would remain at the first level, the tags would be better aligned
>with their
>contents and different informations would appear in different places...

Would your <Status> element ever be used within a <SignResponse>?  It seems 
like it wouldn't.  So I'd rather get rid of the <Result>, and just include 
its children directly:

<xs:element name="SignResponse">
     <xs:complexType>
         <xs:sequence>
             <xs:element ref="ServerProcessingResult">
             <xs:element ref="dss:Signature" minOccurs="0"/>
             <xs:element ref="dss:Outputs" minOccurs="0"/>
         </xs:sequence>
     </xs:complexType>
</xs:element>

<xs:element name="VerifyResponse">
     <xs:complexType>
         <xs:sequence>
             <xs:element ref="ServerProcessingResult">
             <xs:element ref="Status" 
minOccurs="0">
             <xs:element ref="dss:Result"/>
             <xs:element ref="dss:Outputs" minOccurs="0"/>
         </xs:sequence>
     </xs:complexType>
</xs:element>


Still, I find this less... aesthetically pleasing then just re-using a 
single <Status> element for both.  I doubt we're going to convince each 
other, so I think we should try to get some other opinions as a tie-breaker.

What do other people think?

Trevor