(unknown charset) [Issue 341-ml] Inconsistent definition of RespondWith...

(I had forgotten to mail these two)

Hi Matt,

This is just a confirmation message for closing the decision cycle.

The comments you reported[1] were assigned issue id  341-ml[1].

The WG acknowledges your XKMS schema changes but has decided it is 
not convenient to change the schema for additional clarity
at this stage. Your schema changes will be documented in a To-Do list (in
addition to the issues list) so that they can be taken into account 
in future revisions of the XKMS specification.

Could you please acknowledge if you have any objections?

[1] http://www.w3.org/2001/XKMS/Drafts/pr-issues/issues.html#341-ml
http://www.w3.org/2001/XKMS/Drafts/XKMS-REC-DRAFT/REC-DRAFT-xkms-part-1.html

Thanks,

-jose

On Mon, May 23, 2005 at 03:45:28PM -0000, Matt Long wrote:
> Stephen et. al.,
> <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> 
> 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.