[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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. pbaker@verisign.com 781 245 6996 x227 -----Original Message----- From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] 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. pbaker@verisign.com 781 245 6996 x227
Phillip Hallam-Baker (E-mail).vcf
Phillip Hallam-Baker (E-mail).vcf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC