RE: [bt-spec] Votes for 21 March call

[Peter Furniss <peter.furniss@choreology.com>]

Responding to Doug's comments on 29 and 96:

> - 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...

It is very important for a developer (or a binding specifier) to be aware
that the Superior:Inferior relationship is not request/response. The
Inferior -> Superior meesages  PREPARED, CANCELLED, CONFIRMED, RESIGN can be
sent at the initiative of the sending Inferior, and not in response to a
message from the Superior. Their sending may be triggered by a received
mesage, but isn't always. The Inferior -> Superior messages all reflect the
current state of the Inferior, and if the Inferior can change its state as a
result of other stimuli than a received message (which, in most cases, is
not asufficient cause for the state change anyway, though depending on the
use, it may be necessary)

The Superior:Inferior relationship is a persistent, assymetric peer
relationship. Both sides know the others address all the time. Changing it
to request/response would substantially change the protocol, its
relationship to carrier protocols, the capabiliites for spontaneous prepared
and autonomous confirm or cancel decisions and the recovery mechanisms.

The other relationships are request/response (in some cases -
Enroller:Superior - with an optional response)

> 	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.

I'm not sure that you are asking for a change from the spec. I was saying we
*could* use FAULT/redirect in the case of a "response" on
Supeirior:Inferior. I think it is a bad idea. It would get distinctly
complicated, because the Superior can't always tell if a message is really a
"response" or a request that crossed.

But the spec doesn't say that - on Superior:Inferior, only REDIRECT is ever
used - whether sent pre-emptively, or when the receipt of a mis-directed
message suggests the other side doesn't know of the change. (that follows
the pattern of the rest of the superior:inferior protocol - if, for any
reason, one side has reason to believe it's last message has not been
received, it can resend it)


Can you say what change you want in the spec.  I believe the normative part
is unambiguous - there is no capability of sending FAULT/redirect on the
Superior:Inferior relationship, and no capability of sending REDIRECT on any
other relationship. I've revised the text in the model (which is awaiting a
last few contributions).


> 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.

The identifier(s) are always needed - this is a critical part of the
implementation flexibility and carrier independence, described in the a, b,
c bullet list in the section on Addresses at the start of abstract messages.
Since I don't know how many state engines you've got at the address you gave
me, I must label which one I'm speaking to (or from).

The sending, reply and target address are only there to make the delivery
work  - issue 100 makes a sound point (intend to put a "colouring" proposed
solution for that out very shortly). They appear in the abstract messages as
concepts, and, given the variety of potential carriers for the xml encoding,
they need to be optional fields in the xml.

The note does indeed refer to what happens in bindings, and was included
mostly to avoid any mis-apprehension that the fields would necessarily have
real appearance when used over (say) http. No notes are necessary - that's
why they're notes.

Peter


> 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
>