OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [business-transaction] Call for email votes - 4 issues - endsMarch 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