BEEP adjustments [was: Re: I-D ACTION:draft-ietf-sacred-protocol-bss-01.txt]

(No, _this_ message is _not_ about the substrate issue ;)

Stephen,

Thanks for your work in producing this draft.

In order to clarify the separation between the messages themselves and the
BEEP profile more clearly, I suggest that the places where BEEP is
mentioned before the current Section 4 are rewritten slightly.

Specifically, the changes I would like to see are

Section 1:

s/The protocol uses [BEEP]/The protocol is profiled for BEEP [BEEP]/

Section 2.3:

(See separate posting regarding SRP, but in case that is not well
received, at least:

s/sTLS means that the BEEP session MUST be "tuned" for
server-authenticated TLS/sTLS means server-authenticated TLS/

s/cTLS means that the BEEP session MUST be "tuned" for
mutually-authenticated TLS/cTLS means client-authenticated TLS/

s/SRP means that the BEEP session MUST be "tuned" for SASL-SRP;/SRP means
SASL-SRP;/

and then move the para about "tuned" BEEP sessions to the BEEP profile
section.

Section 2.4:

Drop 2.4 since it does not make things more secure or efficient but adds
confusion (e.g. is there some operational requirement that requires the
server to drop the connection after a successful exchange?)

Section 3.1:

Replace the last two paragraphs with:

   "Where no specific response message is defined for an operation (e.g.
   for UploadRequest) then the transport will indicate success or
   failure.

   All of the response messages defined here MAY contain a Status
   string, containing a value intended for human consumption."

(The BEEP profile already specifies the mapping to BEEP messages)

BR,
-- Magnus