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

RE: KeyName white space

From: Ed Simon <ed.simon@entrust.com>
Date: Mon, 14 May 2001 20:35:13 -0400
Message-ID: <7D901CFF4FC51942AF52A0AD43AA3F821B61FC@sottmxs08.entrust.com>
To: w3c-ietf-xmldsig@w3.org
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();


-----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.
> >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
>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/
Received on Monday, 14 May 2001 20:35:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:04 UTC