The Remote Framebuffer Protocol
Note: This ballot was opened for revision 03 and is now closed.
(Cullen Jennings) Yes
(Alexey Melnikov) (was Discuss) Yes
Comment (2009-07-30 for -** No value found for 'p.get_dochistory.rev' **)
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).
(Robert Sparks) (was Discuss, No Objection) Yes
(Ron Bonica) No Objection
(Ralph Droms) No Objection
Comment (2009-07-15 for -** No value found for 'p.get_dochistory.rev' **)
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?
(Lisa Dusseault) No Objection
(Adrian Farrel) (was Discuss) No Objection
(Russ Housley) (was Discuss) No Objection
Comment (2009-07-16 for -** No value found for 'p.get_dochistory.rev' **)
Please place normative and informational references in different subsections.