- From: Joseph Reagle <reagle@w3.org>
- Date: Tue, 5 Mar 2002 13:54:12 -0500
- To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'stephen.farrell@baltimore.ie'" <stephen.farrell@baltimore.ie>, www-xkms@w3.org
On Tuesday 05 March 2002 13:18, Hallam-Baker, Phillip wrote: > > If someone can present a scenario and definitions of what > > these things mean > > I might be more comfortable; otherwise it's seems to be > > optional/advisable > > cruft that's best left out. > > This is a pretty standard approach for protocol compatibility > testing. It is already defined in HTTP. Any ambiguity there is not as likely to cause security problems, particularly as right now the protocl aspect of XKMS is intermingled with the trust semantic bits. Regardless, HTTP clearly defines what these bits mean [1]; it predates XML and SOAP, xmldsig, and xenc all find namespaces sufficient [2]. [1] http://www.ietf.org/rfc/rfc2616.txt 3.1 HTTP Version HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values. The <minor> number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format of a message within the protocol is changed. [2] http://www.w3.org/TR/soap12-part1/#N535 4.1.2 Envelope Versioning Model SOAP does not define a traditional versioning model based on major and minor version numbers. If a SOAP message is received by a SOAP 1.2 node in which the document element information item does NOT have a namespace name of http://www.w3.org/2001/12/soap-envelope the SOAP node MUST treat this as a version error and generate a VersionMismatch SOAP fault (see 4.4 SOAP Fault). See A Version Transition From SOAP/1.1 to SOAP Version 1.2 for further details. Any other malformation of the message structure MUST be treated as a Sender SOAP fault. -- 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 Tuesday, 5 March 2002 13:54:16 UTC