OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wss] White space (was RE: [wss] Proposal for a new attribute of UsernameToken)


I think I agree with Irving. But I think that we should be clear about that in this spec then since we are being very clear about how to use the nonce ("the octet sequence of its decoded value").

I propose the following change:

Change:

"hashed using the octet sequence of its UTF8 encoding as specified in the contents of the element". 

To

"hashed using the octet sequence of its UTF-8 encoding as specified in the contents of the element including any whitespace"

The schema derives the <Created> element from xsd:string so I don't believe that it is otherwise specified what a leading space would mean and I believe that we should leave no doubts in the minds of those implementing our spec.

-Eric


-----Original Message-----
From: Reid, Irving [mailto:irving.reid@hp.com] 
Sent: Tuesday, October 28, 2003 2:49 PM
To: wss
Subject: [wss] White space (was RE: [wss] Proposal for a new attribute of UsernameToken)


> From: Eric Gravengaard [mailto:eric@reactivity.com]
> 
> Reading Jerry's email made me think of something that 
> happened at the interop event back in June. How are leading 
> and trailing white space treated in the computation of the 
> digest? It wasn't clear to me that there couldn't be a 
> trailing or leading space in the format of the date in the 
> <wsu:Created> element. If there was would it change the 
> digest or not? If I'm wrong and there are schema rules for 
> not allowing white space then I apologize for wasting the bandwidth.
> 
> -Eric
> 
> Oh and the interop story was that the part about 
> KeyIdentifiers having white space and most of us not trimming it out.


It's this sort of thing that fuels my "trimming white space is a bad idea" rants. I believe that XML DSig made a serious mistake by specifying that KeyIdentifiers could have non-significant white space around them.

XML gives us a way to represent *exactly* the text we intend. Let's use it that way. Besides, unless you have drunk deeply at the well of Unicode, you might not know white space when you see it. Specifying that text inside XML elements can have leading and/or trailing white space trimmed before processing is a recipe for interop failures.

 - irving -

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]