Might MAKES RIGHT!

Some sundry corrections.
 
I realised that most of the cases of confusion could be eliminated by
changing MAY to might.
 
So might does make right after all!


 
issue_9191	 Clarification/ Joseph Reagle/ Keyword Audit/ [ List
<http://lists.w3.org/Archives/Public/www-xkms/2002Sep/0024.html> email -
09/24/2002]	 [Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> I - 2002/08/01]

[64] The following ResultMajor codes are defined:

The "must" in the table should probably be MUST.
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> 

(Related: Issue
<file:///C:/Documents%20and%20Settings/mjust/Desktop/XKMS%20Issues%20List%20
-%20Oct%207,%202002.htm#issue-18> 18)	 Done with some rewording to
indicate the scope of the MUST	
issue_9393	 Clarification/ Joseph Reagle/ Keyword Audit/ [ List
<http://lists.w3.org/Archives/Public/www-xkms/2002Sep/0024.html> email -
09/24/2002]	 [Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> I - 2002/08/01]

[91] For example a Locate Service MAY act as an aggregator of public key
related information obtained from a variety of sources without performing
any checks to determine whether specific information is current or
establishing any formal trust policy. Such a service would correspond to the
role of a directory in a traditional PKI. A Validate service MAY provide a
service that validates key information presented to it but does not provide
aggregation services.

I think I would lowercase these MAYs.
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> 

(Related: Issue
<file:///C:/Documents%20and%20Settings/mjust/Desktop/XKMS%20Issues%20List%20
-%20Oct%207,%202002.htm#issue-18> 18)	 Used might instead to avoid
confusion
	
issue_9494	 Clarification/ Joseph Reagle/ Keyword Audit/ [ List
<http://lists.w3.org/Archives/Public/www-xkms/2002Sep/0024.html> email -
09/24/2002]	 [Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> I - 2002/08/01]

[202] X-KRSS specifies a mechanism for authenticating requests that is
independent of any authentication mechanism provided by the message security
binding. By its nature the X-KRSS protocol must support requests from
parties who have yet to register their credentials or who have impaired
credentials which are to be revoked.

I think this "must" should be MUST.
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> 

(Related: Issue
<file:///C:/Documents%20and%20Settings/mjust/Desktop/XKMS%20Issues%20List%20
-%20Oct%207,%202002.htm#issue-18> 18)	 
Reworded as I don't think the MUST is actually a protocol MUST it is a
design MUST	
issue_9797	 Clarification/ Joseph Reagle/ Keyword Audit/ [ List
<http://lists.w3.org/Archives/Public/www-xkms/2002Sep/0024.html> email -
09/24/2002]	 [Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> I - 2002/08/01]

[280] Depending on the implementation and application a key recovery
operation MAY involve an unacceptable loss of confidence in the security of
a private key component. This may lead to the possibility of repudiation of
a signed document or of accountability in the case of an encrypted document.

The first may should be lower case.
 
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> 
(Related: Issue
<file:///C:/Documents%20and%20Settings/mjust/Desktop/XKMS%20Issues%20List%20
-%20Oct%207,%202002.htm#issue-18> 18)	 made into a might