WSS-SOAPMessageSecurity-12-04021 issues/edits

[merlin hughes <merlin@baltimore.ie>]

Some small issues/edits from reading half of the doc.

i) Line 186:

The xsd: prefix is also used in the document.

ii) Line 490 and globally:

"A string label" is, to me, a slightly vague definition
for ID attributes; would "An ID label" or some such be
better?

iii) Line 544:

... The ValueType attribute s/allows/is/ a qualified name ...

iv) Line 547 and elsewhere:

If EncodingType is unspecified, I presume that means
base 64; should we say this explicitly? We say 'default'
in some places, but the meaning of that is not altogether
clear to me; I could misinterpret as schema default.

v) Lines 562-566:

Why is it RECOMMENDED that the namespace prefixes be declared
within the wsse:BinarySecurityToken element? They have to be
declared somewhere, in order for the QName to have meaning; so
I'm not sure what this recommendation is adding. If anything,
shouldn't we be requiring that exclusive c14n, if used,
include any non-visibly-utilized namespace prefixes in its
unsuppressed prefix list?

vi) Line 600:

... If a s/SecurityTokenRefeference/SecurityTokenReference is/ used outside ...

vii) Line 601:

... reference s/are// MUST be ...

viii) Line 615:

Does wsse:Usage deserve to be a global attribute? It only
appears to be used once.

ix) Lines 703, 708 and elsewhere:

703: The ValueType attribute is used to optionally indicate
708: The optional EncodingType attribute is used to indicate

If we don't intend a different meaning, I'd suggest
standardizing on the form of line 708.

x) Line 726:

... is used to s/embedded/embed/ a token ...

xi) Lines 730,733:

s/KeyIdentifier/Embedded/

xii) Line 765:

... Additionally, s/defined for// e-mail addresses ...

xiii) Lines 768-777:

Is the font off?

Merlin


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. 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.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com