W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

RE: additional XMLDSIG URIs

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Tue, 17 Apr 2001 18:15:10 -0400
Message-Id: <>
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 

This document could also/alternatively be published as a W3C Note using 
different namespace such as:
(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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:35 UTC