[BEEPwg] Underspecifications in RFC 3080? (profile content, SWS avoidance)
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
> 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.)
> <!-- profile element is empty if contained in a greeting -->
> <!ELEMENT profile (#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.
> For interoperability, the empty-element tag should be used, and
> 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.