- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Wed, 24 Mar 2004 09:19:25 -0800
- To: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
- Cc: Jacek Kopecky <jacek.kopecky@systinet.com>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, XMLP Dist App <xml-dist-app@w3.org>
Jean-Jacques Moreau wrote: > Hum... it's not my recollection and I don't see this in the minutes[1] > either. Did I miss something obvious? > > If we were indeed to use @relay="true", there would be no need for a > special role, and we could simply use "next", as was suggested initially > by Noah. > The relay='true' is useful when the header is not processed. If this is the only semantics needed then we do not need a new role. The issue is what happens when the intermediary processes the header, in which case the semantics of the relay attribute does not apply. So if you never want the Representation header to be removed, then you use the role 'sticky' and relay='true'. > In addition, as Hervé reminded us recently, @relay only helps when a > header block was understood but NOT processed. @relay does not help when > the header block was indeed processed. This is where we need the > additional semantics provided by "sticky" (or whatever it ends up being > called), i.e. always reinsert even if processed. > +1 > Actually, it now really looks to me like we are augmenting our > processing model with this new role. I don't think it's Representation > header specific; hence I prefer the name "sticky" to > "reinsertRepresentation". Simply "reinsert" would be ok. > I think that would be more appropriate. > Obviously, my closing email was so confusing that it generated a lot of > extra discussion. Apologies for not having been clear enough. > > I'll be attending tonight's telcon. > > JJ. > > [1] <http://www.w3.org/2004/03/02-xmlprotocol-irc.txt> > > Anish Karmarkar wrote: > >> >> The resolution IIRC wasn't quite that. >> It wasn't 'always reinserted'. It was -- >> >> Define a new role (name to be decided) that causes a Representation >> header block targeted to it be reinserted if processed. >> >> (removed the always). >> It is always reinserted only if relay is also true. >> >> -Anish >> -- >> >> Jean-Jacques Moreau wrote: >> >>> >>> What about the following amendment to your point 1? >>> >>> <amendment> >>> Define a new role (name to be decided) that causes any Representation >>> header block targeted to it to always be reinserted, even if processed. >>> </amendment> >>> >>> Jacek Kopecky wrote: >>> >>>> Oh, I think your closing email [1] is a bit wrong and a bit confusing: >>>> >>>> it says the five numbered points are characteristics of the new role, >>>> where only the second is, in fact. The first point isn't true (IIRC), >>>> the use of the new role is totally up to the application; a >>>> Representation header can be targeted at any other role and the usual >>>> rules apply, including the points 3a, 3b and 4 in the closing email. >>>> >>>> I think the closing email should be rephrased to something like: >>>> >>>> >>>> At its recent f2f, the XMLP WG decided to close this issue with >>>> the following actions: >>>> 1. define a new role (name to be decided) that >>>> causes all >>>> Representation header blocks targeted to it always to be >>>> reinserted, even if processed. >>>> 2. Note that it's OK for multiple Representation >>>> header blocks >>>> in the same message to have the same URI and role. Such >>>> Representation header blocks would typically have different >>>> metadata. >>>> 3. Note that implementations MAY need to process >>>> Representation >>>> header blocks BEFORE other header blocks that might dereference >>>> URIs. >>>> >>>> >>>> Best regards, >>>> >>>> Jacek Kopecky >>>> >>>> Systinet Corporation >>>> http://www.systinet.com/ >>>> >>>> >>>> [1] http://lists.w3.org/Archives/Public/xmlp-comments/2004Mar/0024.html >>>> >>>> >>>> On Mon, 2004-03-22 at 16:56, Jean-Jacques Moreau wrote: >>>> >>>>> Yes it does! The (agreed) resolution says: "Define a new role as >>>>> above [plus other stuff]". >>>>> >>>>> "Above" says: "Proposal (again): Define a new role. Characteristics >>>>> of this role are; 1. if you process a Rep header targetted at this >>>>> role, you MUST resinsert it." >>>>> >>>>> If point 1. was not to be taken into consideration, why would the >>>>> agreed resolution say "as above"? My reading is that the scribe >>>>> figured out it could save some typing, instead of reinserting >>>>> (again) the whole proposal once more. >>>>> >>>>> You seem to be thinking otherwise. >>>>> >>>>> JJ. >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>
Received on Wednesday, 24 March 2004 12:30:15 UTC