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

From: Jered Floyd <[email-masked]>
Date: 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
-- [email-masked]

_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: Greg Hudson <[email-masked]>
Date: Tue, 30 Oct 2001 01:52:47 -0500

> It is unclear to me, from the above passage, in which character set
> the decoded data should be taken.

As far as the profile is concerned, the initialization element is a
bucket of octets.  The profile gets to decide how they are
interpreted.  See RFC 3080 section 2.2.2.

(In retrospect, it does seem a bit incongruous that initialization
elements do not get headers, and thus do not get a MIME type.  That
would seem to impede a packet tracer's ability to display
initialization elements properly, which is odd since we decided not to
allow profiles to specify default MIME types precisely to help out
packet tracers.  Still, it does not seem to be a specification
ambiguity.)

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

Your solution seems to be searching for a problem, and would appear to
violate the standard.  By my reading, a BEEP library should pass the
initialization element to the application as octets, not as
characters.  (Or the application should pass in the character set it
wants the BEEP library to use to decode the initialization element.)

[...]
[...]
>    should only be used, for elements which are declared EMPTY.

As noted in section 1.2 of REC-xml, "for interoperability" denotes a
non-binding recommendation intended to help out ancient verifying SGML
implementations.  I don't think it's even worth nitpicking.

> I believe that BEEP is vulnerable to SWS.

RFC 3081 section 3.1.4 says:

   o  each time a frame is received, a SEQ frame should be sent whenever
      the window size that will be sent is at least one half of the
      buffer space available to this channel; and,

I believe this provides SWS avoidance.  The section also references
the parts of RFC 1122 which deal with flow control.
_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: Greg Hudson <[email-masked]>
Date: Tue, 30 Oct 2001 09:31:21 -0500

> interpreted.  See RFC 3080 section 2.2.2.

And of course, that doesn't make sense, since the initialization
element might not be base64-encoded, in which case it comes as
characters, not bytes.

So I think this really is ambiguous.  I still don't think adding a
text-encoding attribute is a valid answer for an implementation,
though.  A library could:

  * Pass the PCDATA of the initialization element back to the
    application (as characters), along with a flag saying whether
    encoding="base64" was specified.  Let the application figure out
    what to do with that.

  * Accept a character set specification to be used to decode
    base64-encoded initialization elements; for non-encoded elements,
    just return the PCDATA as characters.

Neither seems great.  But the point is, given that the BEEP
specification is ambiguous here, it is up to the profile to specify
what an encoded and non-encoded initialization element mean.
_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: "Marshall T. Rose" <[email-masked]>
Date: Tue, 30 Oct 2001 09:33:57 -0800

> element might not be base64-encoded, in which case it comes as

we can certainly update the spec, though i'd like to see a concrete proposal
as to what the change is.

perhaps a good solution is to add a new value for the encoding attribute
that specifies that the piggyback is a MIME object that has been encoded
(headers and all) with base64.

for myself, the model i currently use is to undo the base64, if any, and
then pass the piggyback as application/octet-stream to the profile engine...

/mtr

---

From: Jered Floyd <[email-masked]>
Date: 30 Oct 2001 13:43:00 -0500

> (headers and all) with base64.

This is certainly plausible, however if that's the solution I wish we
didn't have the "encoding" attribute on profile at all; the content
could have been a MIME body in itself, with the same default text
encoding and content transfer encoding as a normal BEEP+XML payload.
Unfortunately, such a change would not be backwards compatible.

Perhaps the additional encoding attribute should be "mime", indicating
the content is a MIME document, and the "base64" attribute should be
depricated in favor of "mime" with a Content-Transfer-Encoding: base64
header?

--Jered

---

From: Jered Floyd <[email-masked]>
Date: 30 Oct 2001 13:48:37 -0500

> the parts of RFC 1122 which deal with flow control.

This only fulfills the recipient's responsibilities to SWS avoidance.
(RFC 11.22, Section 4.2.3.3.)  I believe that RFC 3081 should also
explicitly state the sender's responsibilities as well. (Section
4.2.3.4) While the above quote from RFC 3081 allows to recipient to
discourage sends from the peer when little window space is available,
nothing in the RFC discourages the sender from (in general) sending
small payloads.  The sender's responsibilities were important enough
to mention in RFC 1122, and so I think they're important enough to
mention in RFC 3081 as well.

--Jered

---

From: Chris Laas <[email-masked]>
Date: Tue, 30 Oct 2001 14:02:24 -0500

> taken to be in the same character set as the enclosing MIME body.

I remain unconvinced that this is an ambiguity in the BEEP spec.  If
the "encoding" attribute does not have the value "base64", then the
content's character set is specified by the MIME type of the enclosing
message, and the content is passed to the application as characters.
If the "encoding" attribute is "base64", then the content is simply a
chunk of octets; it may be assumed to have the MIME type
application/octet-stream if it's convenient.  Where is the ambiguity?

--Chris

---

From: Jered Floyd <[email-masked]>
Date: 30 Oct 2001 14:18:31 -0500

> application/octet-stream if it's convenient.  Where is the ambiguity?

This provides no opportunity for the character set of this
base64-encoded initialization message to be specified, if it is to be
interpreted as character data.  My impression of the BEEP spec is
that, much as MIME content transfer encodings, the "encoding"
attribute should be transparent to the application such that proxies
along the way may translate between content-preserving encodings.

What you propose requires two distinct interfaces to an application
using BEEP, one for encoding='none' which provides a character stream
to the application, one for encoding='base64' which provides a byte
stream with no associated metadata.  This is poor design.

--Jered

---

From: Chris Laas <[email-masked]>
Date: Tue, 30 Oct 2001 14:25:57 -0500

> along the way may translate between content-preserving encodings.

While it may have been your impression, it seems clear to me that the
spec says something entirely different.

> stream with no associated metadata.  This is poor design.

Well, I would not claim that this is an example of good design.
However, I would claim that the spec is unambiguous, and that, as
specified, BEEP cannot allow this interface to be transparent to the
application.  If you wanted the interface you outline above, you'd
technically have to change the spec (as has been pointed out, it's
certainly an option).

On the other hand, the "require encoding=base64 contents to be
MIME-encoded" solution could easily be implemented as a thin layer
atop BEEP; it doesn't seem entirely odious to me that this feature
could be handled at the application layer.

--Chris