- From: <noah_mendelsohn@us.ibm.com>
- Date: Tue, 22 Oct 2002 11:26:09 -0400
- To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
- Cc: "Kirill Gavrylyuk" <kirillg@microsoft.com>, "Martin Gudgin" <mgudgin@microsoft.com>, xml-dist-app@w3.org
Henrik Frystyk Nielsen suggests: >> "In all cases where a SOAP header block is processed, the SOAP node >> MUST understand the SOAP header block and MUST do such processing in a >> manner fully conformant with the specification for that header block. >> Successful processing of one header block does not guarantee >> successful processing of another block with the same fully qualified >> name within the same message." I don't have a problem with the intent, but this wording comes close to implying that a node need not consistently >>understand<< headers, and I don't think that's what we mean. We're clear that understanding is based on having and coding for the specification for a qname. I'm a bit nervous about appearing to say that again, but if we want to, I'd suggest: <proposed> "In all cases where a SOAP header block is processed, the SOAP node MUST understand the SOAP header block and MUST do such processing in a manner fully conformant with the specification for that header block; because understanding is a function of the qualified name of the header (see 2.4 Understanding SOAP Header blocks), a given node must consistently understand or not understand any header blocks that share a common qualified name within a single message. Nonetheless, the successful processing of one header block does not guarantee successful processing of another block with the same fully qualified name within the same message: the specification for the header determines the circumstances in which such processing would result in a fault." </proposed> ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Tuesday, 22 October 2002 11:29:21 UTC