Re: [wss] about Hitachi's negative vote

[Yutaka Kudo <yutaka@sdl.hitachi.co.jp>]

Dear TC members,

I thought the specs could be read without ambiguity if there were 
descriptions like these.

----------
(1) Add following statment to [WSS] Chapter 2;

This document's URI is:
http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message
-security-1.0

This URI is also used as the prefix for EncodingType identifiers,
ValueType identifiers, and algorithm identifiers by this document.
We use URI fragment to provide compact and readable examples.
For example URI fragment "#Base64Binary" corresponds to full URI
"http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-
message-security-1.0#Base64Binary".
The full URI MUST be used by implementation and the URI fragments MUST 
NOT be used.

(2) Add similar statement to [WSSUSERNAME] and [WSS-X509].

(3) Change following statment;

"the URI for this specification" -> "document's URI"

[WSS] Line 598
[WSSUSERNAME] Line 170, 236
[WSS-X509] Line 178, 218
--------

Best regards,
Yutaka Kudo, Hitachi.

---------
Yutaka Kudo, Researcher.
Web Services, 202 Research Unit.
Systems Development Labo. Hitachi, Ltd.



> -----Original Message-----
> From: Yutaka Kudo <yutaka@sdl.hitachi.co.jp>
> Sent: Mon, 05 Apr 2004 22:36:08 +0900
> To: wss@lists.oasis-open.org
> Subject: [wss] about Hitachi's negative vote
>
>
>Dear TC Members,
>
>I'm very sorry for late explanation about Hitachi's negative vote. 
>We, Hitachi never had intention to disapprove the proposed standard, but 
>we have a concern to be clarified before publishing this spec. we are 
>just hoping that the spec has to become better for all of readers. We 
>are very sorry to confuse all of TC members especially chairs and 
>editors.
>
>Our concern was raised from the 3rd (recent general) Interop. This 
>Interop was done between TC ballot and OASIS ballot, so our (Hitachi's) 
>vote conflicts with prior TC vote.
>
>We were very pleased to join the interop and it was very successful, so 
>if our concern is resolved, we really agree that proposed standard to be 
>approved.
>
>I show our concern as follows, and I'd like to discuss and clarify it.
>
>WS-Security uses URIs for the value of type attribute, e.g. ValueType 
>attribute and EncodingType attribute. In the proposed specification, 
>definition of such URIs is in the form of URI fragment. But the base 
>URIs of these fragments are not clear at least for us. 
>
>Actually, at the beginning of the 3rd Interop testing, some companies' 
>implementation failed to interoperate. Because I think this is important 
>issue on this spec, I'd like to propose amendment. I'd like to discuss 
>among the TC members whether we should put this amendment into errata 
>document or submit as an amendment specification.
>
>The description regarding the URIs are as follows;
>--------------------
>- EncodingType of <wsse:BinarySecurityToken> ([WSS] Line 598)
>  note that the URI fragments are relative to the URI for this 
>specification
>
>- ValueType of <wsse:KeyIdentifier> ([WSS] Line 760)
>  Note that URI fragments are relative to this document's URI
>
>- STR-Transform algorithm ([WSS] Line 972)
>  Note that URI fragments are relative to this document's URI
>
>- Type of <wsse:Password> ([WSSUSERNAME] Line 170)
>  note that the URI fragments are relative to the URI for this 
>specification
>
>- ValueType of <wsse:SecurityTokenReference> ([WSSUSERNAME] Line 236)
>  note that the URI fragments are relative to the URI for this 
>specification
>
>- Token types ([WSS-X509] Line 178)
>  note that URI fragments are relative to the URI for this specification
>
>- ValueType of <wsse:KeyIdentifier> ([WSS-X509] Line 218)
>  note that URI fragments are relative to the URI for this 
>specification).
>-------------------
>
>It is not clear for us what the "URI for this specification" and "this
>document's URI" means.
>
>At the 3rd Interop, we used the following three values those are the 
>Location URI of each document;
>
>- For URIs defined in "SOAP Message Security 1.0" ([WSS] Line 9)
>http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message
>-security-1.0
>
>- For URIs defined in "UsernameToken Profile 1.0" ([WSSUSERNAME] line 8)
>http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
>token-profile-1.0
>
>- For URIs defined in "X.509 Certificate Token Profile" ([WSS-X509] Line 
>8)
>http://www.docs.oasis-open.org/wss/2003/12/oasis-200401-wss-x509-token-
>profile-1.0
>
>It is confusing for us because there are two Location URIs for each 
>docuemnt, "http://www.oasis-open.org/committees/documents.php"; and the 
>URLs listed above.
>
>------ References ------
>[WSS]         oasis-200401-wss-soap-message-security-1.0.pdf(15 March 
>2004)
>[WSSUSERNAME] oasis-200401-wss-username-token-profile-1.0.pdf(15 March 
>2004)
>[WSS-X509]    oasis-200401-wss-x509-token-profile-1.0.pdf(15 March 2004)
>------------------------
>
>Also, we are wondering that the Location URI should be used, because the 
>Location URI is the location of the repository. The meaning of the 
>"Location" is described in "Specification Template Instructions" as 
>follows;
>--------------------
>Location:
>The location (base URI) of the "repository" where versions of this 
>document can be retrieved.
>--------------------
>http://www.oasis-open.org/spectools/docs/wd-spectools-instructions-02.
>html#s.metadata
>
>At the beginning of 3rd Interop, some vendors(including Hitachi) used 
>the namespace URI of WS-Security, that is;
>http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
>secext-1.0.xsd
>
>WS-I Basic Security Profile WG also uses the namespace URI in their 
>profile.
>
>So we propose
>(1) To obtain the agreement among the TC members about the value of URIs.
>(2) To use same wording for base URI, "URI for this specification" or 
>"this document's URI"
>(3) To write the values of URIs clearly in the spec.
>
>For reference, I extract the descritption of "XML Encryption". I think 
>this might be a good example for our spec also.
>--------------------
>The experimental XML namespace [XML-NS] URI that MUST be used by 
>implementations of this (dated) specification is:
>   xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'
>This namespace is also used as the prefix for algorithm identifiers used 
>by this specification. While applications MUST support XML and XML 
>namespaces, the use of internal entities [XML, section 4.2.1], the "xenc" 
>XML namespace prefix [XML-NS, section 2] and defaulting/scoping 
>conventions are OPTIONAL;
>we use these facilities to provide compact and readable examples.
>Additionally, the entity &xenc; is defined so as to provide short-hand
>identifiers for URIs defined in this specification. For example
>"&xenc;Element" corresponds to "http://www.w3.org/2001/04/xmlenc#Element";.
>--------------------
>http://www.w3.org/TR/xmlenc-core/#sec-Versions
>
>
>TC has to take action within 30 days, and I believe that our choice is
> (a) or (c). (errata or amendment)
>
>http://www.oasis-open.org/committees/process.php#standard
>--
>(a) request OASIS TC Administration to approve the specification as
>submitted despite the negative votes; (b) withdraw the submission
>entirely; or (c) submit an amended specification.
>--
>
>Thank you,
>
>Yutaka Kudo. Hitachi, Ltd.
>
>
>---------
>Yutaka Kudo, Researcher.
>Web Services, 202 Research Unit.
>Systems Development Labo. Hitachi, Ltd.
>
>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.