- From: Jacek Kopecky <jacek@idoox.com>
- Date: Tue, 12 Jun 2001 09:47:56 +0200 (CEST)
- To: Herve Ruellan <ruellan@crf.canon.fr>
- cc: <xml-dist-app@w3.org>
Herve, I agree that "MUST by default" is somewhat suspicious, I'm not yet good enough in English to be able to state my point concisely and more clearly. From your two choices I would choose the second but it doesn't say that if the intermediary doesn't know anything about the trailers, it MUST forward them. On the other hand I do want the intermediaries to be allowed to change/remove the trailers if they (think they) know what they are doing. Adding a changed trailer doesn't let you change the data that other headers may point to, you can only change the data that the headers you put in point to. We have yet to resolve pointing to various blocks of the message and it might be useful to separate this from the data encoding. Jacek Kopecky Idoox On Tue, 12 Jun 2001, Herve Ruellan wrote: > Jacek, > > Jacek Kopecky wrote: > > > > [ snip ] > > > > Proposal #1 > > =========== > > "Trailers are not subject to the processing rules for > > header/body entries described in Section 2. However, the > > information carried in a trailer may be accessed when processing > > header/body entries. > > Intermediaries MUST by default (unless they know otherwise) > > forward the trailers unchanged with the forwarded message." > > [ snip ] > > I think you made a good point that the proposal should state not only > if intermediaries are allowed to remove trailers but also if they are > allowed to change them. > However, I think this last sentence should either be: > 1. Intermediaries MUST forward the trailers unchanged with the > forwarded message. > 2. Intermediaries SHOULD forward the trailers unchanged with the > forwarded message. > > I would prefer 1, as if an intermediary really need to change the > content of a trailer, it may just add a new trailer with the updated > content, leaving the older trailer unchanged for any other part of > the message referring to it. > > Hervé. >
Received on Tuesday, 12 June 2001 03:48:06 UTC