[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [bt-spec] Re: [business-transaction] Call for email votes - 4 issues -ends March 27
My votes: Issue 29: AGAINST. Following Doug, I think that the issue of "not request-response" needs to be discussed in more depth. I can live with what's there, but I'm voting NO so we can have a focused discussion. Doug's comment about explaining to a developer why this isn't consistent is quite telling. Issue 96: AGAINST. Again, following Doug, and wanting a clear discussion of his specific points. I guess this discussion will have to be in the April 3rd meeting. Issue 98: Issue 106: Doug Bunting wrote: > Votes for myself, Doug Bunting, the one sending this message, et > cetera. (Should be fairly obvious since OASIS process doesn't support > proxy votes). > > - Issue 29: Redirection (revote) > AGAINST - current proposal adds value by providing the "carrier > protocol" option for REDIRECT but complicates the situation by adding > the FAULT/redirect. Changes as they stand do not explain REDIRECT > versus FAULT/redirect clearly. When a request / response message (such > as PREPARE / PREPARED) travels over the Superior:Inferior relationship, > why can't the receiver respond with Fault/redirect? On other > relationships, if the receiver has the address of the sender, should > they also send a REDIRECT message? > When I previously made these comments [1], Peter [2] mentioned that > PREPARE / PREPARED aren't "strictly a request/response pair" which is a > distinction I'd rather not have to explain to a developer... > > In general, why are there two mechanisms to carry the same > information? This "feels like" creating a new message to cover the > difference between a PREPARED message sent to register an autonomous > decision versus one sent in reply to PREPARE. Allowing REDIRECT > (explicitly or implicitly using the new and good carrier protocol > option) to be used in reply seems much cleaner. > When I previously made these comments [1], Peter replied [2] with "We > could use the FAULT as the response on the Superior:Inferior > relationships when it is reply to a misdirected message (which would > include both PREPARE and PREPARED for example), but we would still need > REDIRECT as a "change of address" postcard (often sent pre-emptively on > a carrier request from the *new* address)." > This seems significantly easier to understand and more consistent with > other parts of our specification. > > Issue 96: Reply address on SUPERIOR, INFERIOR_STATUS > AGAINST - Again, we have complications arising from our decision to > support "unstrict" request / response pairs. This particular solution > worsens many things because it adds another variant of address requiring > additional explanation. If 'the "sender-address" is treated as the > "reply-address" of the other messages', the first question will be "why > don't these messages have a reply-address?" I don't think we have an > easy answer. > Adding sender-address removes the need for at least one *-identifier in > each message. Including both sender-address and inferior-identifier in > PREPARED (for example) is redundant but the identifiers will be > necessary in any binding that removes the need for the full > sender-address. > The proposed Note in the first insertion is not necessary and should be > / is described as part of the various bindings. As mentioned above, > when removing sender-address for a particular binding, it will often be > necessary to add back the appropriate *-identifier. The current binding > description doesn't seem to cover this case. > > Issue 98: MIME-Version should not be HTTP header > For > Issue 106: Free text for all FAULTs > For > > thanx, > doug > > [1] http://lists.oasis-open.org/archives/bt-spec/200203/msg00022.html > [2] http://lists.oasis-open.org/archives/bt-spec/200203/msg00024.html > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
Attachment:
william.cox.vcf
Description: Card for William Cox
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC