[BEEPwg] Underspecifications in RFC 3080? (profile content, SWS avoidance)

Jered Floyd jered@permabit.com
30 Oct 2001 00:09:15 -0500


I've come across three items in RFCs 3080/3081 that are causing me
some confusion.  I'm hoping that you can clear these up for me.

RFC 3080, Section 2.3.1.2 The Start Message, [p. 17]:
   [...]
   o  each "profile" element contained with the "start" element has a
      "uri" attribute, an optional "encoding" attribute, and arbitrary
      character data as content:

      *  the "uri" attribute authoritatively identifies the profile;

      *  the "encoding" attribute, if present, specifies whether the
         content of the "profile" element is represented as a base64-
         encoded string; and,

      *  the content of the "profile" element, if present, must be no
         longer than 4K octets in length and specifies an initialization
         message given to the channel as soon as it is created.
   [...]

Consider the situation where content is provided, and the "encoding"
attribute has the value "base64".  It is unclear to me, from the above
passage, in which character set the decoded data should be taken.  The
intuitive answer is to claim that the decoded base64 data should be
taken to be in the same character set as the enclosing MIME body.

While tempting, I believe this is incorrect.  The MIME body may have
undergone translation in transit, either internal to the BEEP library,
or within a BEEP protocol proxy.  Unfortunately, the only solution I
can come up with is to say that the "profile" element contained within
a "start" message may also optionally have a "text-encoding"
attribute, defaulting to "UTF-8", specifying the text encoding of
base64-encoded data.  Does anyone have a better solution?


This next one is really a nitpick:
RFC 3080, Section 7.1 BEEP Channel Management DTD, [p. 49]:
   [...]
   <!-- profile element is empty if contained in a greeting -->
   <!ELEMENT profile     (#PCDATA)>
   <!ATTLIST profile
             uri         %URI;              #REQUIRED
             encoding    (none|base64)      "none">
   [...]

My concern here is that the comment here is just that, a comment. It
is a semantic check that cannot be performed by a validating XML 
processor, only by the channel management implementation itself. As
such, the DTD claims that element "profile" contains PCDATA.

In RFC 3080, Section 2.3.1, all uses of "profile" in "greeting"
elements, and many uses of "profile" in "start" elements, make use
of the XML empty element notation, "<element/>".  This is poor XML.
The "Extensible Markup Language (XML) 1.0 (Second Edition)" W3C
recommendation, section 3.1 Start-Tags, End-Tags, and Empty-Element
Tags, states:

   Empty-element tags may be used for any element which has no 
   content, whether or not it is declared using the keyword EMPTY.
   For interoperability, the empty-element tag should be used, and
   should only be used, for elements which are declared EMPTY.


Finally, an issue that RFC 3081 fails to address, that perhaps ought
to be addressed in RFC 3080 as well.  "Mapping the BEEP Core onto TCP"
adopts the concept of window-based flow control from TCP.
Unfortunately, it fails to adopt TCP's mechanisms for minimizing
framing overhead (the Nagle algorithm, RFC 896; and SWS avoidance, RFC
1122, Section 4.2.3.4).  Thus, nothing in RFC 3080 or 3081 discourages
a BEEP from sending many frames with single-byte payloads, either due
to poor implementation, or TCP-like Silly Window Syndrome [SWS].

I believe that BEEP is vulnerable to SWS.  The Nagle algorithm is not
necessary as I believe one should never expect 'interactive'
performance for frames within a single BEEP message; however the SWS
avoidance mechanisms described in RFC 1122 are applicable.  Thus, I
believe that RFC 3081 (perhaps Section 3.1.2?) should be amended
to include wording along the lines of:

   A BEEP implementation MUST include a SWS avoidance algorithm in the
   sender, in order to avoid excessive framing overhead due to poor
   fragmentation of a message into frames.

   To avoid sending many small frames, a BEEP should not generate a
   frame unless:

      o  a maximum-sized frame can be sent; i.e. a frame can be
         generated that is the full MSS of the underlying transport;
         or

      o  a frame of at least one-half of the maximum window size
         advertised may be sent [NOTE: This condition is mostly a
         formality; given that the TCP mapping defines a minimum 4K
         window size, this condition would only be met on a TCP socket
         with an MSS greater than or equal to 2K.  This is the case on
         the loopback interface on many operating systems, but not on
         any networks of which I am aware.]; or

      o  a frame containing all remaining data on a message may be
         generated.

This text would alleviate my concerns of poor network utilization by
BEEP; the above are the guidelines that my implementation follows and
that I believe should be universal.


Please let me know if I should provide further clarification on any
of these concerns!  Thank you for your time.

-- Jered Floyd
-- jered@permabit.com