Subject: Comments on the mbus internet draft

From: Robert Slagter <[email-masked]>
Date: Fri, 31 Mar 2000 16:15:07 +0200

After reading "draft-ietf-mmusic-mbus-transport-01.txt", concerning a
message bus for local coordination, I have some comments:

* There is an inconsistency between sections 7.2 and 7.3: while section
7.2 defines that an mbus message consists of a message header and at
least one mbus command, section 7.3 states that the header is followed
by zero, or more, commands.
Section 7.3 is correct in my opinion, as it should be possible for an
mbus message to only contain an acknowledgement, which is transmitted in
the message header (as described in section 7.2).

* Appendix A describes the address element keys. The list provided in
that section should in my opinion be extended with the key "id", which
describes a unique identifier of the instance of the conferencing
application. The rest of the appendix suggests this, but the key is just
not mentioned in the list.

Furthermore, I wonder why section 8.5 defines that a "GO" message must
be sent via unicast. What is the reason for not using multicast? Just
that the message is by definition always sent to one receiver?

Kind regards,
    Robert Slagter

--
   Ir. Robert Slagter

   member of scientific staff
   Telematica Instituut
   P.O. Box 589, 7500 AN Enschede, The Netherlands

   Tel. 053 - 4850 488
   Fax: 053 - 4850 400
   E-mail: [email-masked]
_________________________________________________________________________

---

From: Dirk Kutscher <[email-masked]>
Date: 31 Mar 2000 18:24:38 +0200

>>>>> "Robert" == Robert Slagter <[email-masked]> writes:

    Robert> * There is an inconsistency between sections 7.2 and 7.3:
    Robert> while section 7.2 defines that an mbus message consists of
    Robert> a message header and at least one mbus command, section
    Robert> 7.3 states that the header is followed by zero, or more,
    Robert> commands.  Section 7.3 is correct in my opinion, as it
    Robert> should be possible for an mbus message to only contain an
    Robert> acknowledgement, which is transmitted in the message
    Robert> header (as described in section 7.2).

Robert, 

true, section 7.2 needs to be corrected.

    Robert> * Appendix A describes the address element keys. The list
    Robert> provided in that section should in my opinion be extended
    Robert> with the key "id", which describes a unique identifier of
    Robert> the instance of the conferencing application. The rest of
    Robert> the appendix suggests this, but the key is just not
    Robert> mentioned in the list.

OK, the appendix should list the application specific address element
keys for conferencing applications *in addition* to the mandatory
id-element. There is however a problem because we talk of "5 address
element keys" but then name only 4 and in another paragraph below we
mention the "instance" element that has been replaced by "id". I will
fix that too and clarify the section.

    Robert> Furthermore, I wonder why section 8.5 defines that a "GO"
    Robert> message must be sent via unicast. What is the reason for
    Robert> not using multicast? Just that the message is by
    Robert> definition always sent to one receiver?

And that it has to be sent reliably -- which is only defined for
unicast messages. The idea is that an entity that has received a
"waiting" command records the sender address of the corresponding
message and uses this in a follow-up "go" command to signal that the
condition has been satisfied. In order to avoid that waiting entities
can block because they missed a "go" we decided to require the
reliable transmission.

-- 
Thanks for your comments,

	Dirk