Re: Semantic Nit -2

Hi Matt,

I definitely would not support changing the schema for additional
clarity at this stage. So, unless we start to hear a clamor from
WG participant's I think we'll continue with the current schema.

I'm also unsure (without checking) that every e.g. LocateRequest
MUST have a populated RespondWith - I can imagine that policy
or implementation based defaulting would be ok in many cases.

 From Tommy's mail it appears that he at least omits RespondWith
elements when he doesn't have a good value, rather than including
the element with no value. I guess client code that can handle
either case would be better, but that Tommy's server's behaviour
is fine as a SHOULD (unless servers do different things here?).

So perhaps the right condition is that relevant requests MAY
include RespondWith(s) and when they do, associated responses
SHOULD include relevant values where those are available to
the server, and SHOULD NOT include the relevant element when
the server has no good value to include in the response.
Clients MUST be able to handle responses which omit the
requested element entirely, or which include the element
but with no value.

The above needs to be rewritten using the appropriate
formal terms, but do we all think its otherwise ok? (If so,
we can park this discussion for now and let Shivaram do
the wordsmithing when he gets around to editing the spec.)

Stephen.

Matt Long wrote:

> Stephen et. al.,
> 
>  
> 
> After further review of my proposed text and my issues with the text of Section 
> 3.2.3 (RespondWith)
> 
> -        Use of terms strings is semantically incorrect.
> 
> -        More RFC[2119] terminology needed for clarity.
> 
>  
> 
> has led me, unfortunately, to another issue [1] and proposal [2].  However, with 
> the new proposal this issue, the proposed text for 3.2.3 [102], clearly 
> specifies ‘which’ requests the <RespondWith> element is associated.  Thereby, 
> allowing the semantic accuracy of SHOULD and MUST into the text of the definition.
> 
>  
> 
> New Proposed Text for Section 3.2.3 [102]
> 
> [102]The <RespondWith> element allows the sender of a request to specify which 
> data elements SHOULD be provided in the response.  One or more <RespondWith> 
> elements MUST be included as immediate children of the request where each 
> element URI value is an identifier that corresponds to either an immediate child 
> element of <ds:KeyInfo> or the private key information defined in section 
> Cryptographic Algorithm Specific Parameters below. The XML Signature elements 
> are described here for convenience. The normative reference is the specification 
> [XML-SIG].
> 
>  
> 
>  
> 
>  
> 
> [1]
> 
> Issue: Inconsistent definition of RespondWith element usage with 
> RequestAbstractType.
> 
>  
> 
> The <RespondWith> element in the XKMS schema is optional because the following 
> request types MUST NOT include a <RespondWith> element(s) as immediate children.
> 
>  
> 
> PendingRequest, CompondRequest, StatusRequest
> 
>  
> 
> The following request types REQUIRE the use of one or more <RespondWith> elements.
> 
>  
> 
> LocateRequest, ValidateRequest, RegisterRequest, ReissueRequest, RevokeRequest, 
> RecoverRequest.
> 
>  
> 
> [2]
> 
> Proposal:
> 
> A more accurate representation of the RespondWith element is to remove the 
> RespondWith element reference from the RequestAbstractType, then extend a new 
> type with RequestAbstractType that includes a RespondWith element reference 
> (one…unbound) in the new type.  Then extend the requests that require the 
> RespondWith element by the new type NOT RequestAbstractType.  In this manner, 
> <RespondWith> can be clearly defined for the applicable requests.
> 
>  
> 
> <complexType name="RequestWithAbstractType" abstract="true">
> 
> <complexContent>
> 
> <extension base="xkms:RequestAbstractType">
> 
> <sequence>
> 
> <element ref="xkms:RespondWith" minOccurs="1" maxOccurs="unbounded"/>
> 
> </sequence>
> 
> </extension>
> 
> </complexContent>
> 
> </complexType>
> 
>  
> 
> 
> 
> 
> 
>     --------- Original Message --------
>     From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
>     To: "Matt Long" <mlong@mvsquared.net>
>     Cc: www-xkms@w3.org
>     Subject: Re: Semantic Nit -2
>     Date: 23/05/05 05:39
> 
> 
> 
> 
>     Matt,
> 
>     I think that this is ok, but want to check that the MAY
>     is correct here.
> 
>     I guess, (without checking) that if a client includes
>     a RespondWith that a server SHOULD include a corresponding
>     element in the response, at least if it has a meaningful
>     value to place in the element. However, I could buy an
>     argument that MAY is right, since a server might want to
>     ignore such a value for some policy reason.
> 
>     So, two follow-ups:
> 
>     - Can anyone save me the trouble of checking through the
>     spec to verify whether MAY or SHOULD is right here?
>     - For the implementers - what does your code do if you
>     have no good value to include in the response element?
>     (E.g. Do you omit the element entirely, or include the
>     element, but without anything inside?)
> 
>     And lastly, this seems to be a case where we're adding
>     a new potentially testable assertion. I think that that
>     means that we just need to be careful to note that
>     the spec and test-spec get slightly out of whack at
>     the point where we include this change. I'm not
>     bothered that this happens, btw, since the test-spec
>     was for the PR transition which has happened already.
>     (At least I hope that that's ok according to the
>     w3c-process rules of the road;-)
> 
>     Stephen.
> 
>     Matt Long wrote:
> 
>      > Issue: Section 3.2.3 [1]
>      > - Use of terms strings is semantically incorrect.
>      > - More RFC[2119] terminology needed for clarity.
>      >
>      > Section 3.2.3 [102] states:
>      > ”[102]The <RespondWith> element in the request specifies one or more
>      > strings included in the request that specify data elements to be
>      > provided in the <ds:Keyinfo> element of the response. Each string is a
>      > single identifier corresponding to a sub-element of the XML Signature
>      > Specification [XML-SIG]
>      > <http://www.w3.org/TR/xkms2/#XML-SIG#XML-SIG><ds:Keyinfo> element or
>      > the private key information defined in the section Cryptographic
>      > Algorithm Specific Parameters
>      > <http://www.w3.org/TR/xkms2/#privatekeyparameters#privatekeyparameters>
>      > below. The XML Signature elements are described here for convenience.
>      > The normative reference is the specification [XML-SIG].”
>      >
>      > Purposed Text:
>      > [102]The <RespondWith> element allows the sender of a request to specify
>      > which data elements MAY be provided in the <ds:KeyInfo> element in the
>      > response. One or more <RespondWith> elements MAY be included in a
>      > request where each <RespondWith> element URI value is an identifier than
>      > corresponds to either a sub-element of the XML Signature Specification
>      > [XML-SIG] <ds:KeyInfo> or the private key information defined in section
>      > Cryptographic Algorithm Specific Parameters below. The XML Signature
>      > elements are described here for convenience. The normative reference is
>      > the specification [XML-SIG].
>      >
>      > Justification:
>      > (1)Eliminates the term ‘strings’ where URI is required.
>      > (2)Specifies ‘MAY’ for <ds:KeyInfo> sub-element response items, which is
>      > accurate.
>      > (3)Disambiguates the element’s value as the identifier.
>      >
>      >
>      >
>      > --
>      > Matt Long
>      > MV Squared Technologies
>      > mlong@mvsquared.net <mailto:mlong@mvsquared.net>
>      > 901-848-2640
>      >
>      >
>      >
>      > ________________________________________________
>      > Message sent using UebiMiau 2.7.2
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ________________________________________________
> Message sent using UebiMiau 2.7.2

Received on Tuesday, 24 May 2005 09:12:20 UTC