W3C home > Mailing lists > Public > www-xkms@w3.org > May 2002

xkms f2f minutes comments

From: Frederick Hirsch <hirsch@fjhirsch.com>
Date: Wed, 15 May 2002 13:20:15 -0400
Message-ID: <3CE298CF.90601@fjhirsch.com>
To: www-xkms@w3.org, hirsch@fjhirsch.com
I have a couple of comments on the F2F minutes.

1). It would be helpful to provide HTML targets for the items so we
could link to them from the issues list, (eg. <A NAME="issue-1"></A> for
Issue 1 etc.

It would also be useful to make the Editors Issues an alphabetic list
with targets, for the same reason. (e.g. a. Give examples...)

2) For Issue 8, I believe we decided that QName issue was out of scope
for the requirements (although an issue for the spec) (the minutes show 
??? resolution)

3) Trust relationship _ I'm not sure the issue was bias, but rather the
need to provide some other examples. (Does anyone have any additional 
examples?)

4) The heading "Eliminate the requirement for interoperability" could be
misinterpreted. The issue was whether to eliminate support for opaque
data in requests and responses for the sake of interoperability. We
agreed to retain support for opaque data since it can be ignored.

5) The heading "remove non-repudiation from out of scope" could be
misleading. We resolved this by fixing the conflicting requirement 2.5.2
(It was "The specification SHOULD enable finer granularity of key usage
definition to support compliance requirements. Signatures may be
supported for specific purposes, such as approval, authorship or
integrity for example. One possible way of meeting this requirement is
to define a <Purpose> subtype for the <KeyUsage> element."

and is now

"A key registration request MUST be able to specify the appropriate key
usage of a key."

6) Under the introspection item, we also revised the requirement at the
meeting to be

"A server MAY be deployed that implements a subset of XKMS service
functionality, such as Locate but not Validate, for example."

7) We resolved the "XML Extensions" issue at the F2F to allow XML
extensibility since such (XML Namespace) extensions leverage XML
extensibility and may be ignored.

8) Please correct the spelling of my name in various places, including
the atttendance and elsewhere (Frederick Hirsch)

9) On the spec open floor issues, I thought we agreed to use XML
namespaces for versioning and eliminate the versioning mechanism in the
spec.

10) I also thought we discussed the issue of KeyInfo vs KeyBinding and
decided to retain the distinction and not extend KeyInfo

thanks

Frederick Hirsch
hirsch@fjhirsch.com
Received on Wednesday, 15 May 2002 13:20:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:16 GMT