- From: <noah_mendelsohn@us.ibm.com>
- Date: Tue, 1 Oct 2002 10:51:32 -0400
- To: "Martin Gudgin" <mgudgin@microsoft.com>
- Cc: xml-dist-app@w3.org
Martin Gudgin writes: >> I don't expect people to sign the envelope. >> I think people will sign individual headers, >> groups thereof or the body. As an 80/20 cut, I agree completely, but why preclude it. One could take the view that the simplest case is: what I put in, I get out. Now, if an intermediary really needs to put a header in, that's a change to the message and a signature should break. If, however, we just want to make sure the message came out as sent (which doesn't preclude that headers showed up along the way as long as they were then stripped), then I think it's a really simple model to say that the infoset shows up intact, or at least that we don't specifically license unnecessary changes. Conversely, if we go with your proposal, why would it not be more appropriate to make it symmetric and to say (roughly): "A soapenv:Header with no children is semantically equivalent to providing no soapenv:Header element at all; either representation may be used when sending a message with no header entries, and intermediaries are free to insert or remove such empty header element information items when relaying a message." Why: Presumably your change is to allow an intermediary to build up some abstract list of headers, and to just use a canonical form when sending. I can think of at least as many cases in which the intermediary would want to unconditionally send the (possibly empty) element as to remove it. So, I think I'd either say "preserve it" (first choice, but not a strong preference) or "feel free to change it either way." Remove only doesn't make as much sense to me. Thanks. ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Tuesday, 1 October 2002 10:53:57 UTC