- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Tue, 17 Apr 2001 18:15:10 -0400
- To: "Brian LaMacchia" <bal@microsoft.com>
- Cc: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, <w3c-ietf-xmldsig@w3.org>, <lde008@dms.isg.mot.com>
At 14:11 4/17/2001 -0700, Brian LaMacchia wrote:
>1) Why did you choose to use URLs that were not of the form
>"http://www.w3.org/2000/09/xmldsig#<something>", where the something is
>sha256, sha284, etc. Ideally these should probably be NIST-defined
>identifiers, and failing that I would have expected them to follow the
>XMLDSIG naming scheme.
Good question. The simple bit is since they aren't defined by the dsig
namespace (and the resource you get back when you resolve that URI) they
shouldn't be in that namespace by W3C policy. Once we reach REC (hopefully
very soon) our namespace and its meaning is frozen (and we don't want to
delay/recycle specifying/debugging/waiting-for-implementation on these
algorithms).
This document could also/alternatively be published as a W3C Note using
different namespace such as:
http://www.w3.org/2001/05/xmldsig-extension#
(and again, the W3C would require that this namespace resolve to something,
most probably the W3C Note, but that's easy on the W3C side). I'm curious
what people think about using *.arpa domain (from the ietf-draft [1]) that
doesn't resolve for these informational/non-normative identifiers.
[1] ftp://ftp.ietf.org/internet-drafts/draft-eastlake-uri-fqdn-param-00.txt
As an aside, and directly to Don's draft, if folks want to go the *.arpa
route, I find using the host to identify the type of algorithm as an
additional complexity in namespace parsing/recognition.
__
Joseph Reagle Jr. http://www.w3.org/People/Reagle/
W3C Policy Analyst mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature
W3C XML Encryption Chair http://www.w3.org/Encryption/2001/
Received on Tuesday, 17 April 2001 18:15:25 UTC