[bt-spec] Votes for 21 March call

[Doug Bunting <db134722@iPlanet.com>]

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