FW: Proposed new schema

All, 
 
    Attached is a proposed new schema with the collected changes made as set
out bellow with the one proviso that #34 has NOT been performed.
 
    The naming convention adopted in the schema, for better or worse is
little-endian so that the qualifiers to a root type are prefixed. So a
specialization of the abstract KeyBinding for a Query becomes
QueryKeyBinding in the same way that the locate specialization of Request is
LocateRequest and so on.
 
    I have not yet updated the documents to match.
 
            Phill
 
 
 
#
	Type &
Source	 Specification Reference &
Issue Description
	Proposed Resolution Details (incl Date)&
Volunteer (Specification editor(s) if blank)
	
issue_1616
	Editorial/
Brian LaMacchia [ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F]	 [Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> I - 2002/08/01]

In Section 2.3.1, in the MessageAbstractType, the type for Nonce is
ds:CryptoBinary.  This is fine if the Nonce is a number, but typically an IV
is encoded with Base64.
	Ensure that a Nonce supports both types. [ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F] 


No, actually make base64...

issue_2020
	Major/
Blake Dournaee [ List
<http://lists.w3.org/Archives/Public/www-xkms/2002Aug/0031.html> email -
08/30/02]
	[Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> I - 2002/08/01]

There is some confusion regarding the structure of the <Status> element and
its <StatusValue> child. In particular, there seems to be different status
values that should be returned depending on whether a Locate or Validate
request is performed.  

(Related: Issue
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#issue-67> 67)
	Separate <KeyBinding> into  <KeyBindingLocate> and
<KeyBindingValidate>. It's not clear whether a similar split is required for
<QueryKeyBinding>. Redesign <Status>. [ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F]

Phill Hallam-Baker, Brian LaMacchia
	
issue_2323
	Major/
Blair Dillaway
[ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F]	 [Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> I - 2002/08/01] [Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_II-2002-
08-01> II - 2002/08/01]

Related to Issue
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#issue-22> 22,
there is a need to support other bulk requests (i.e. for Location,
Validation, ...)
	Support for multiple requests, for all request types, should be
added.  A proposed solution for dealing with responses to multiple requests
is required (including how to deal with a pending indication for only part
of the request). [ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F]

Phill Hallam-Baker, Brian LaMacchia
	
issue_3030
	Major/
Dan Ash
[ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F]	 [Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> I - 2002/08/01]

In addition to the use of the tail end of the request URI for specifying
policy, there is some consensus for explicitly adding a policy URI to the
request.
	Add a policy URI to the request.  It should be extensible using
subtyping.   [ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F]


	
issue_3131
	Major/
Brian LaMacchia
[ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F]	 [Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> I - 2002/08/01] [Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_II-2002-
08-01> II - 2002/08/01]

As a generalization of the solution for Issue
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#issue-30> 30,
instances of "any" should be removed from the schema, in favour of using
subtyping for extensibility.
	Remove all instances of "any" in favour of subtyping. [ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F]	
issue_3232
	Major/
Phill Hallam-Baker
[ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F]	 [Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> I - 2002/08/01]

"RespondWith" is currently confusing since it asks for elements that relate
both to objects and to information about the current session.
	Split "RespondWith" into two elements that specify the data elements
to be returned, and those elements that are protocol-dependent (e.g.
Multiple).  Also, extend to include ValidityInterval, KeyUsage and
UseKeyWith (which at least partially deals with Issue
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#issue-29> 29
as well) [ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F]	
issue_3434
	Editorial/
Shivaram Mysore
[ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F]	 [Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> I - 2002/08/01] [Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_II-2002-
08-01> II - 2002/08/01]

Rename "QueryKeyBinding" and "PrototypeKeyBinding" to "KeyBindingQuery" and
"KeyBinding Prototype" respectively.
	Make changes as described. [ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F]	
issue_6161
	Major/
Blake Dournaee [ List
<http://lists.w3.org/Archives/Public/www-xkms/2002Aug/0031.html> email -
08/30/02]
	[Part
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Part_I-2002-0
8-01> I - 2002/08/01]

When I first read the description of <KeyUsage> my initial thought was akin
to PKIX keyUsageExtension. I suppose I'm wondering if the three options
provided (Signature,Encryption,Exchange) are going to be augmented to allow
other key usage semantics. Doing this, however, would simply move the
complexity from the underlying PKI back to the message syntax. What argument
is there to keep the three choices that do exist there while leaving others
out (for example, keyCertSign, crlSign)?
	Add a separate, optional element for communicating X.509 certificate
attributes (OID value).[ Sept
<http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list.html#Sept_2002_-_F
2F_Meeting_Minutes> 2002 F2F]