- From: <noah_mendelsohn@us.ibm.com>
- Date: Tue, 8 Oct 2002 15:40:15 -0400
- To: Marc Hadley <marc.hadley@sun.com>
- Cc: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>, "Martin Gudgin" <mgudgin@microsoft.com>, moreau@crf.canon.fr, Nilo.Mitra@am1.ericsson.se, www-archive@w3.org
Mark Hadley asks: >> Why is it important that the header *not* be "mustUnderstand='1'" ? The scenario is: a bunch of SOAP implementations get deployed and set up as intermediaries and endpoints along a path. Afterawhile, I discover there is some information I want to include in my messages and that information is really for anyone who cares. Maybe I want to put in a "TimeSent" header. Is it mU? No. If you don't care that's harmless. It will only be understood selectively as individual intermediaries are redepoloyed with software that can take advantage of the sending time info. What's the problem? As soon as it hits an intermediary that wasn't updated, the header disappears. The alternative Henrik suggests, I believe, is: either use an application specific role (ICareAboutTime) or a general relaying Role (IDontRemoveNotUnderstoodHeaders) and claim that any node implementing the chosen role agrees not to remove headers, even headers that it doesn't process. I'm concerned that this is at least a serious stretch of the processing model which says: if you play the role, you must remove it. You can only reinsert if you have some specific reeason based on processing. To read that as: "well actually, you can leave it in if you know something special about the role" seems to go well beyond what we imply. So, there's a use case and a problem, I think. How serious is a matter of judgement, which is why I'm waffling on raising as a real issue. >> I agree that role shouldn't be overloaded in this manner. I'm pretty sure I do too. Thanks. ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Tuesday, 8 October 2002 15:42:54 UTC