FW: AcceptXMLNS element

Found in drafts, did this go out? Anyone interested in the idea?

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.

781 245 6996 x227


-----Original Message-----
From: Hallam-Baker, Phillip [mailto:]
Sent: Friday, July 13, 2001 2:46 PM
To: OASIS SSTC List
Subject: AcceptXMLNS element


All,

	One of the issues to be considered in the protocol section is
feature discovery, IE how does the client know what features the service
offers and how does the client tell the service which features that it can
handle?

	This has two levels;
		A: does X have the capacity to support Y for some request?
		B: does X have the capacity to support Y for this specific
request?

Possible Ys include
	Attribute schemas
	Extension schemas specifying assertion types, condition types,
advice etc.

The mechanism by which the server features are discovered are likely to
include WSDL. This is not likely to solve case B but is useful for
specifying the maximal set of features, even if they might not be supported
for all principals.

For discovery of client features it is likely to be desirable to indicate
the features in the request. There are many dimensions across which the
feature set might be described. One necessary dimension is the xml
namespaces that the client understands, I suspect that this is also
sufficient but others may argue otherwise.

This argues for the addition of the following to the RequestType in the new
schema (which has not been circulated yet):

	<xsd:complexType name="RequestType">
		<xsd:complexContent>
			<xsd:extension base="samlp:AbstractRequestType">
				<xsd:choice>
					....
					<xsd:element name="AcceptXMLNS"
type="uriReference"
	
minOccurs="0" maxOccurs="unbounded"/>
				</xsd:choice>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>

Since this did not appear on the whiteboard it will not be in the consensus
schema, however the issue was raised at the F2F and there was general
consensus something needed to be done.

One of the uses of the Respond element was to provide this information,
spliting it out into a separate element probably made sense then. Now that
we don't have a respond element we need a slot for this information.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.

781 245 6996 x227