W3C home > Mailing lists > Public > xml-dist-app@w3.org > June 2001

Re: Issue 25 Proposals from the f2f

From: Jacek Kopecky <jacek@idoox.com>
Date: Tue, 12 Jun 2001 10:38:41 +0200 (CEST)
To: Herve Ruellan <ruellan@crf.canon.fr>
cc: <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0106121028550.23769-100000@bimbo.in.idoox.com>
 Herve,
 I think that if some data is shared and somebody interested
doesn't know it, something is broken. No, this is too strong of a
statement.
 In other words, if the data is meant to be shared, sharing is
OK. If the contract of the message route says that somewhere the
data will change and we don't want the change to be shared, we
can have two copies from the start and the change will occur only
in one copy - it won't be shared. Yes, optimizing here would be
useful, but it would be a complex thing to do.
 So we have two choices:
 1) intermediaries must not change/remove trailers, they can add
them.
 2) intermediaries can, if they really want to, change/remove
trailers.

 The drawbacks of these options are (AFAICS):
 The first option makes impossible the scenario where you only
want to transfer trailing data to an intermediary and no further,
or where you want to change the shared data.
 The second option puts more burden on the architect of the
application to get things right.

 The advantages of these options are:
 The first option simplifies the rules and the processing.
 The second option is more flexible.

 If there is anything I missed, please anyone speak up.

 My opinion is that the second option is still simple enough and
that the added flexibility is useful so I vote for 2. 8-)

                            Jacek Kopecky
                               Idoox



On Tue, 12 Jun 2001, Herve Ruellan wrote:

 > Jacek,
 >
 > I agree with you that we have to solve the problem of cross
 > references between blocks.
 >
 > I had the feeling that the first proposal for handling headers aimed at
 > being simple and safe. This is why I suggested the first solution that
 > an intermediary MUST NOT change any trailer (an in any case MUST
 > forward them).
 >
 > I agree that this raises a problem when several parts of a message
 > refer to the same trailer and an intermediary really want to
 > change the thing refered by all those parts. But I think that the
 > other way around may also occur, when several parts of a message
 > refer to the same trailer and an intermediary want to change the thing
 > refered by one of those parts and don't know at all about the other
 > parts.
 >
 > Hervé.
 >
 > Jacek Kopecky wrote:
 > >
 > >  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
 >
Received on Tuesday, 12 June 2001 04:38:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:01 GMT