The Remote Framebuffer Protocol
RFC 6143

[Ballot comment]
[I moved from Discuss to Abstain, since I do not really believe the one added sentence in the
security considerations really addressed the issue but do not believe the community's interest
is served by further delay.  My original discuss text follows.]

I believe that the security considerations section needs to be expanded.  Readers need more
guidance to determine when the standard security types might be acceptable.  Some of the
necessary information is implied in section 7.2.2:

  This type of authentication is known to be cryptographically weak and
  is not intended for use on untrusted networks.  Many implementations
  will want to use stronger security, such as running the session over
  an encrypted channel provided by IPSEC [RFC4301] or SSH [RFC4254].

It would be interesting to hear when the security type "none" is considered appropriate.  I tend
to believe that "none" is inappropriate and should not be used unless security is being handled
unless security is being handled by IPsec, SSH, etc...

[Ballot comment]
I am very glad that this protocol is going to be documented in an RFC.

I don't expect you to do anything about the following comments. If a future version of this protocol is developed in IETF, I hope they can be addressed:

7.5.6.  ClientCutText

  RFB provides limited support for synchronizing the "cut buffer" of
  selected text between client and server.  This message tells the
  server that the client has new ISO 8859-1 (Latin-1) text in its cut
  buffer.  Ends of lines are represented by the newline character (hex
  0a) alone.  No carriage-return (hex 0d) is used.  There is no way to
  transfer text outside the Latin-1 character set.

:-(


I am also hoping that a future version can integrate the SASL authentication framework (RFC 4422).


And finally, language tags can be used for human readable text (RFC 4646).

[Ballot discuss]
Two simple Discusses that can be cleared with minor text or after an
email exchange.

===

Section 1 notes...
  fairly good interoperability
Would it be worth explaining the interoperability issues. Are
they a reuslt of bugs, misunderstandings of the specification,
or options? Does the documentation of RFB in this way mean that
some implementations will be automatically made non-conformant?

===

The note in the tracker says...
  Port 5500 should not be used and is only mentioned for
  historical context.
This is fine, but surely the document should be updated accordingly.

[Ballot discuss]
I believe that the security considerations section needs to be expanded.  Readers need more
guidance to determine when the standard security types might be acceptable.  Some of the
necessary information is implied in section 7.2.2:

  This type of authentication is known to be cryptographically weak and
  is not intended for use on untrusted networks.  Many implementations
  will want to use stronger security, such as running the session over
  an encrypted channel provided by IPSEC [RFC4301] or SSH [RFC4254].

It would be interesting to hear when the security type "none" is considered appropriate.  I tend
to believe that "none" is inappropriate and should not be used unless security is being handled
unless security is being handled by IPsec, SSH, etc...

[Ballot comment]
Section 6 mentions that several versions of RFB have been published.  Would it be possible to add references to the docs in which those versions have been published?  Or is it the intention of this doc to obsolete those earlier docs?

[Ballot comment]
I assume values of padding fields are ignored? Or do they have to contain all zeros?


I don't expect you to do anything about the following comments. If a future version of this protocol is developed in IETF, I hope they can be addressed:

7.5.6.  ClientCutText

  RFB provides limited support for synchronizing the "cut buffer" of
  selected text between client and server.  This message tells the
  server that the client has new ISO 8859-1 (Latin-1) text in its cut
  buffer.  Ends of lines are represented by the newline character (hex
  0a) alone.  No carriage-return (hex 0d) is used.  There is no way to
  transfer text outside the Latin-1 character set.

:-(


I am also hoping that a future version can integrate the SASL authentication framework (RFC 4422).


And finally, language tags can be used for human readable text (RFC 4646).

[Ballot discuss]
I am very glad that this protocol is going to be documented in an RFC.
I have a couple of nits which I want to discuss before voting Yes on this document and I am perfectly fine with them being addressed (if I am right) as RFC Editor notes:

1). In Section 7.7.5:

You lost me here:

  TRLE makes use of a new type CPIXEL (compressed pixel).  This is the
  same as a PIXEL for the agreed pixel format, except where true-color-
  flag is non-zero, bits-per-pixel is 32, depth is 24 or less and all
  of the bits making up the red, green and blue intensities fit in
  either the least significant 3 bytes or the most significant 3 bytes.
  In this case a CPIXEL is only 3 bytes long, and contains the least

What is "this" referring to here?

  significant or the most significant 3 bytes as appropriate.
  bytesPerCPixel is the number of bytes in a CPIXEL.


Is this paragraph just trying to say that each pixed is encoded as 3 bytes?

Some example would be helpful here.

2). In the same section:

  Each tile begins with a subencoding type byte.  The top bit of this
  byte is set if the tile has been run-length encoded, clear otherwise.
  The bottom seven bits indicate the size of the palette used: zero
  means no palette, one means that the tile is of a single color, and 2
  to 127 indicate a palette of that size.  The special values 129 and
  127 indicate that the palette is to be reused from the previous tile,

First you say that the palette size can be 127, but then you say that 127 is a special value. I think you meant "2 to 126 indicate a palette of that size".

  with and without RLE respectively.

[Ballot comment]
I assume values of padding fields is ignored (or does it have to contain all zeros)?


I don't expect you to do anything about the following comments. If a future version of this protocol is developed in IETF, I hope they can be addressed:

7.5.6.  ClientCutText

  RFB provides limited support for synchronizing the "cut buffer" of
  selected text between client and server.  This message tells the
  server that the client has new ISO 8859-1 (Latin-1) text in its cut
  buffer.  Ends of lines are represented by the newline character (hex
  0a) alone.  No carriage-return (hex 0d) is used.  There is no way to
  transfer text outside the Latin-1 character set.

:-(


I am also hoping that a future version can integrate the SASL authentication framework (RFC 4422).


And finally, language tags can be used for human readable text (RFC 4646).

[Ballot discuss]
I am very glad that this protocol is going to be documented in an RFC.
I have a couple of nits which I want to discuss before voting Yes on this document and I am perfectly fine with them being addressed (if I am right) as RFC Editor notes:

1). In Section 7.7.5:

You lost me here:

  TRLE makes use of a new type CPIXEL (compressed pixel).  This is the
  same as a PIXEL for the agreed pixel format, except where true-color-
  flag is non-zero, bits-per-pixel is 32, depth is 24 or less and all
  of the bits making up the red, green and blue intensities fit in
  either the least significant 3 bytes or the most significant 3 bytes.
  In this case a CPIXEL is only 3 bytes long, and contains the least

What is "this" referring to here?

  significant or the most significant 3 bytes as appropriate.
  bytesPerCPixel is the number of bytes in a CPIXEL.


Is this paragraph just trying to say that each pixed is encoded as 3 bytes?

Some example would be helpful here.

2). In the same section:

  Each tile begins with a subencoding type byte.  The top bit of this
  byte is set if the tile has been run-length encoded, clear otherwise.
  The bottom seven bits indicate the size of the palette used: zero
  means no palette, one means that the tile is of a single color, and 2
  to 127 indicate a palette of that size.  The special values 129 and
  127 indicate that the palette is to be reused from the previous tile,

First you say that the palette size can be 127, but the you say that 127 is special. I think you meant "2 to 126 indicate a palette of that size".

  with and without RLE respectively.

IANA questions/comments:

NOTE: In section 2 you refer to port 5500, but that port is registered to
another protocol.

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.