heads up: updated the XKMS part-1 changelog

Hi,

I finished updating the changelog[1]. I temporarily left Shivaram's
precedent text right below the new one, just so that people can verify if
I didn't miss any issue. Unless I hear otherwise, I'll remove Shivaram's
old changelog text in 24 h.

I think part-1 is virtually done. There are just two open questions for
Shivaram and we need to update one issue when part-2 is done. You'll find
those questions as a list of all the changes I applied to the spec. here
below.

-jose

[1]
http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-PUB/PR-PUB-xkms-part-1.html#XKMS_2_0_Section_Appendix_F

----------------------
To Do:
----------------------

[ ] Ask Shiv. if in p. 134 the wording shouldn't be:
   In the case of a non-compound request, the operation that completed s/is with/has/ 
   status Success. 

[ ] Ask Shiv. why there are some items with '*' in the table below [104].

[ ] Supress the previous changelog info

----------------------
Done
----------------------

[X] p. [125]
    Vamsi: The "ds:signature/ds:signatureValue" representation format syntax
    should be replaced by a textual description for consistancy.

    Changed to:

     The content of the <ds:SignatureValue> element used in the request does not 
     match the content of the <RequestSignatureValue> element in the response.

[X] 2.5.3.3
    The spec doesn't specify how to send notifications. This example is misleading.
    Tommy proposes the following text (and I like it):

    "The XKMS service notifies the client about the completion of the request 
     processing using the notification mechanism specified in the 
    <PendingNotification> element in the initial request".

     --> Added Tommy's text and removed the example.

[X] Homogeneize XKISS and XKRSS
    Sometimes the spec uses X-KISS, sometimes XKISS. Same thing for XKRSS.

    Used X-KISS and X-KRSS throughout

[X] [404] Fix font face for URL

[X] Appendix B move to non normative.

[X] 122 TooManyResponses missing a nbsp;
    
[X] Tables at p. [120] and [122]
    The anyURI prefix description looks ugly. Move it to the preceding par.
    
[X] Table at [122]. Use of Sender or Receiver for the last three minor codes
    Tommy proposes Sender. The text in the spec is not synch. with the
    actual values. See [213], [311], [315], 

    Following a mail exchange with Tommy on the list, and with Shivaram's approval,
    modified as follows:

      OptionalElementNotSupported Receiver
      ProofOfPosessionRequired    Sender
      TimeInstantNotSupported     Receiver
      TimeInstantOutofRange       Sender

    --> related par. updated.

[X] Par. [373a] is missing some articles, but I'm unable to fix it
  without knowing what was it supposed to say originally.

  Fixed with Shivaram

[X] 124 and 125 add <span class="ID> as needed.

[X] Added par. ID to all the tables in Section 9 and updated the Changelog
    reference to [354] (the [354] markup was badly placed). Added captions
    and xhtml:thead to these tables.

[X] Together with Shivaram, reorganized table [354d] "Security Bindings" of
    Section 9: Conformance

[X] The text in [128a] implied that the RespondWith element couldn't be a
    descendant of a CompoundRequest element. Changed the text to say that
    it cannot be a direct child, but that it can appear in the inner requests.

[X] Added a missing article in [288] and changed "A second advantage" to
    "an advantage".

[X] Added a better description on how pending requests, notification and polling 
    interact (submitted by TL). Changes to [55], [56]. Inserted new section 
    2.5.2 describing the Status Request and readjusted the subsequent sibling 
    section numbers. Added an SMTP notification example to 2.5.4.1. 

[X] Removed ResponseMechanism.Represent from [54]

[X] Removed the ResponseId element in 2.5.3. as it was a typo

[X] Update the changelog to reflect all but the minor edits I applied

---------------

Received on Monday, 18 April 2005 15:41:16 UTC