[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [bt-spec] Votes for 21 March call
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC