RE: KeyName white space

While I understand the sentiment behind this proposal, I believe it
would be a mistake.  We have specified that KeyName is a String value
whose semantic meaning is defined solely by the sender & recipient.
It's a transport mechanism for a string, that's all -- any rules about
proper format, contents, etc., thus are application-specific.
 
I can all too easily envision, unfortunately, scenarios for KeyName
where automatically stripping off white space would break
interoperability.  Consider the case where the KeyName is actually a
filename telling the recipient where to look in a local key cache for
the verification key.  Filenames on many operating systems can have
spaces in them, including leading spaces.  Alternatively, suppose that
the value of KeyName was used as a database lookup key, and it was
space-padded to be of fixed length.
 
(Here's another example, although specific to Microsoft.  On Win32
platforms, it is likely that folks would use KeyName to store CryptoAPI
key container names.  Rules for container name validity are defined by
each algorithm implementation (crypto service provider -- CSP).  A
limitation like this could create all sorts of weird behaviors...)
 
Let's leave KeyName as just a string.
 
                    --bal
 

	-----Original Message-----
	From: Ed Simon [mailto:ed.simon@entrust.com] 
	Sent: Monday, May 14, 2001 5:35 PM
	To: w3c-ietf-xmldsig@w3.org
	Subject: RE: KeyName white space 
	
	

	1. The schema will not prevent people from having leading or
trailing whitespace in the content of KeyName (and it shouldn't!).  The
spec will just say that any leading and trailing whitespace MUST be
trimmed to obtain the actual KeyName.

	2. The code will look something like this: 

	  Node nodeKeyName = XPathAPI.selectNode(doc,
"//KeyName/text()");  // get the text content of <KeyName> 
	  String strNodeKeyName = nodeKeyName.nodeValue(); 
	  String strKeyName = strNodeKeyName.trim(); 
	  KeyResolver.resolveWithKeyName(strKeyName); 

	Ed 

	-----Original Message----- 
	From: Joseph M. Reagle Jr. [mailto:reagle@w3.org] 
	Sent: Monday, May 14, 2001 6:18 PM 
	To: merlin 
	Cc: Donald E. Eastlake 3rd; w3c-ietf-xmldsig@w3.org 
	Subject: Re: KeyName white space 


	I don't think I completely understand the problem yet. Is this
to say that 

	1. the content model for KeyName should be precluded from having
a 
	white-space as the first or last character? (Not sure if this is
possible 
	using XML Schema patterns [1] since they don't support ^ and $.)

	2. That a processor will not have those white spaces available
to them? 
	(What happens if people want to use generic xml tools like query
or XPath 
	where the whitespace is preserved/important) 

	[1]
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#element-pattern 

	At 22:18 5/14/2001 +0100, merlin wrote: 
	>Agreed. DNames already have this property (from RFC 2253 I
think), 
	>and I believe so do base-64 coded data as well as integers, so 
	>this would unify pretty much all of our text handling. 
	> 
	>merlin 
	> 
	>r/dee3@torque.pothole.com/2001.05.14/14:35:23 
	> >Hi, 
	> > 
	> >Some questions have arisen about in the XML Encryption
activity the 
	> >handling of white space in the content of the KeyName
element. There 
	> >was substantial feeling there that leading and trailing
whitespace 
	> >should be stripped from KeyName content.  I think this would
be an 
	> >improvement but since it is in the XMLDSIG namespace, this
list is 
	> >the right place for discussion.  What do others think? 
	> > 
	> >Thanks, 
	> >Donald 
	>
>===================================================================== 
	> > Donald E. Eastlake 3rd
dee3@torque.pothole.com 
	> > 155 Beaver Street                                +1
508-634-2066(h) 
	> > Milford, MA 01757 USA                            +1
508-261-5434(w) 
	> > 
	> 
	> 
	
>-----------------------------------------------------------------------
------ 
	>Baltimore Technologies plc will not be liable for 
	>direct,  special,  indirect 
	>or consequential  damages  arising  from  alteration of  the
contents of this 
	>message by a third party or as a result of any virus being
passed on. 
	> 
	>In addition, certain Marketing collateral may be added from
time to time to 
	>promote Baltimore Technologies products, services, Global
e-Security or 
	>appearance at trade shows and conferences. 
	> 
	>This footnote confirms that this email message has been swept
by 
	>Baltimore MIMEsweeper for Content Security threats, including 
	>computer viruses. 
	>    http://www.baltimore.com 


	__ 
	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/