Imported Upstream version 3.7

30 files changed, 1098 insertions, 1179 deletions

diff --git a/docs/api/remctl.3 b/docs/api/remctl.3
index 46ee28b..1c88f4a 100644
--- a/docs/api/remctl.3
+++ b/docs/api/remctl.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.26)
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -38,6 +38,8 @@
 .    ds PI \(*p
 .    ds L" ``
 .    ds R" ''
+.    ds C`
+.    ds C'
 'br\}
 .\"
 .\" Escape single quotes in literal strings from groff's Unicode transform.
@@ -48,17 +50,24 @@
 .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
-.ie \nF \{\
-.    de IX
-.    tm Index:\\$1\t\\n%\t"\\$2"
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
 ..
-.    nr % 0
-.    rr F
-.\}
-.el \{\
-.    de IX
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
 .\}
+.rr rF
 .\"
 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
@@ -124,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL 3"
-.TH REMCTL 3 "2013-08-14" "3.6" "remctl Library Reference"
+.TH REMCTL 3 "2014-01-06" "3.7" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -152,8 +161,8 @@ result as a remctl_result struct.
 port to connect to; if 0, the library first attempts to connect to the
 registered port of 4373 and then tries the legacy port of 4444 if that
 fails.  Future versions of the library will drop this fallback to 4444.
-\&\fIprincipal\fR is the service principal to use for authentication; if \s-1NULL\s0,
-\&\f(CW\*(C`host/\f(CIhost\f(CW\*(C'\fR is used, with the realm determined by domain-realm
+\&\fIprincipal\fR is the service principal to use for authentication; if \s-1NULL,
+\&\s0\f(CW\*(C`host/\f(CIhost\f(CW\*(C'\fR is used, with the realm determined by domain-realm
 mapping.  \fIcommand\fR is the command to run as a NULL-terminated array of
 NUL-terminated strings.
 .PP
@@ -206,13 +215,13 @@ in \fIremctl_new\fR\|(3), \fIremctl_open\fR\|(3), \fIremctl_commandv\fR\|(3), an
 on failure to allocate space to store an error message.  Otherwise, it
 returns a newly allocated remctl_result struct with either an error
 message in the error field or the results of the command filled out as
-described above.  If \fIremctl()\fR returns \s-1NULL\s0, errno will be set to an
+described above.  If \fIremctl()\fR returns \s-1NULL,\s0 errno will be set to an
 appropriate error code (generally \s-1ENOMEM\s0).
 .SH "CAVEATS"
 .IX Header "CAVEATS"
-If the \fIprincipal\fR argument to \fIremctl()\fR is \s-1NULL\s0, most GSS-API libraries
+If the \fIprincipal\fR argument to \fIremctl()\fR is \s-1NULL,\s0 most GSS-API libraries
 will canonicalize the \fIhost\fR using \s-1DNS\s0 before deriving the principal name
-from it.  This means that when connecting to a remctl server via a \s-1CNAME\s0,
+from it.  This means that when connecting to a remctl server via a \s-1CNAME,\s0
 \&\fIremctl()\fR will normally authenticate using a principal based on the
 canonical name of the host instead of the specified \fIhost\fR parameter.
 This behavior may cause problems if two consecutive \s-1DNS\s0 lookups of \fIhost\fR
@@ -247,7 +256,7 @@ remctl protocol are available from its web page at
 <http://www.eyrie.org/~eagle/software/remctl/>.
 .SH "AUTHOR"
 .IX Header "AUTHOR"
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 .SH "COPYRIGHT AND LICENSE"
 .IX Header "COPYRIGHT AND LICENSE"
 Copyright 2007, 2008, 2009 The Board of Trustees of the Leland Stanford
diff --git a/docs/api/remctl.pod b/docs/api/remctl.pod
index d2c27a2..a01bf74 100644
--- a/docs/api/remctl.pod
+++ b/docs/api/remctl.pod
@@ -127,7 +127,7 @@ L<http://www.eyrie.org/~eagle/software/remctl/>.
 
 =head1 AUTHOR
 
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 
 =head1 COPYRIGHT AND LICENSE
 
diff --git a/docs/api/remctl_close.3 b/docs/api/remctl_close.3
index 372b0c5..23bb47e 100644
--- a/docs/api/remctl_close.3
+++ b/docs/api/remctl_close.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.26)
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -38,6 +38,8 @@
 .    ds PI \(*p
 .    ds L" ``
 .    ds R" ''
+.    ds C`
+.    ds C'
 'br\}
 .\"
 .\" Escape single quotes in literal strings from groff's Unicode transform.
@@ -48,17 +50,24 @@
 .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
-.ie \nF \{\
-.    de IX
-.    tm Index:\\$1\t\\n%\t"\\$2"
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
 ..
-.    nr % 0
-.    rr F
-.\}
-.el \{\
-.    de IX
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
 .\}
+.rr rF
 .\"
 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
@@ -124,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_CLOSE 3"
-.TH REMCTL_CLOSE 3 "2013-08-14" "3.6" "remctl Library Reference"
+.TH REMCTL_CLOSE 3 "2014-01-06" "3.7" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -156,7 +165,7 @@ remctl protocol are available from its web page at
 <http://www.eyrie.org/~eagle/software/remctl/>.
 .SH "AUTHOR"
 .IX Header "AUTHOR"
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 .SH "COPYRIGHT AND LICENSE"
 .IX Header "COPYRIGHT AND LICENSE"
 Copyright 2007, 2009 The Board of Trustees of the Leland Stanford Junior
diff --git a/docs/api/remctl_close.pod b/docs/api/remctl_close.pod
index 1ebd964..9508a80 100644
--- a/docs/api/remctl_close.pod
+++ b/docs/api/remctl_close.pod
@@ -33,7 +33,7 @@ L<http://www.eyrie.org/~eagle/software/remctl/>.
 
 =head1 AUTHOR
 
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 
 =head1 COPYRIGHT AND LICENSE
 
diff --git a/docs/api/remctl_command.3 b/docs/api/remctl_command.3
index 0d033d7..546d758 100644
--- a/docs/api/remctl_command.3
+++ b/docs/api/remctl_command.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.26)
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -38,6 +38,8 @@
 .    ds PI \(*p
 .    ds L" ``
 .    ds R" ''
+.    ds C`
+.    ds C'
 'br\}
 .\"
 .\" Escape single quotes in literal strings from groff's Unicode transform.
@@ -48,17 +50,24 @@
 .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
-.ie \nF \{\
-.    de IX
-.    tm Index:\\$1\t\\n%\t"\\$2"
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
 ..
-.    nr % 0
-.    rr F
-.\}
-.el \{\
-.    de IX
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
 .\}
+.rr rF
 .\"
 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
@@ -124,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_COMMAND 3"
-.TH REMCTL_COMMAND 3 "2013-08-14" "3.6" "remctl Library Reference"
+.TH REMCTL_COMMAND 3 "2014-01-06" "3.7" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -173,7 +182,7 @@ remctl protocol are available from its web page at
 <http://www.eyrie.org/~eagle/software/remctl/>.
 .SH "AUTHOR"
 .IX Header "AUTHOR"
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 .SH "COPYRIGHT AND LICENSE"
 .IX Header "COPYRIGHT AND LICENSE"
 Copyright 2007, 2009 The Board of Trustees of the Leland Stanford Junior
diff --git a/docs/api/remctl_command.pod b/docs/api/remctl_command.pod
index af952a7..915b73d 100644
--- a/docs/api/remctl_command.pod
+++ b/docs/api/remctl_command.pod
@@ -51,7 +51,7 @@ L<http://www.eyrie.org/~eagle/software/remctl/>.
 
 =head1 AUTHOR
 
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 
 =head1 COPYRIGHT AND LICENSE
 
diff --git a/docs/api/remctl_error.3 b/docs/api/remctl_error.3
index e3a3bfe..99488a8 100644
--- a/docs/api/remctl_error.3
+++ b/docs/api/remctl_error.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.26)
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -38,6 +38,8 @@
 .    ds PI \(*p
 .    ds L" ``
 .    ds R" ''
+.    ds C`
+.    ds C'
 'br\}
 .\"
 .\" Escape single quotes in literal strings from groff's Unicode transform.
@@ -48,17 +50,24 @@
 .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
-.ie \nF \{\
-.    de IX
-.    tm Index:\\$1\t\\n%\t"\\$2"
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
 ..
-.    nr % 0
-.    rr F
-.\}
-.el \{\
-.    de IX
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
 .\}
+.rr rF
 .\"
 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
@@ -124,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_ERROR 3"
-.TH REMCTL_ERROR 3 "2013-08-14" "3.6" "remctl Library Reference"
+.TH REMCTL_ERROR 3 "2014-01-06" "3.7" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -151,7 +160,7 @@ remctl \s-1API\s0 function with the same client object, other than
 .SH "RETURN VALUE"
 .IX Header "RETURN VALUE"
 \&\fIremctl_error()\fR returns either the previous error or the constant string
-\&\*(L"No error\*(R".  It will never return \s-1NULL\s0.
+\&\*(L"No error\*(R".  It will never return \s-1NULL.\s0
 .SH "SEE ALSO"
 .IX Header "SEE ALSO"
 \&\fIremctl_new\fR\|(3), \fIremctl_open\fR\|(3), \fIremctl_command\fR\|(3), \fIremctl_commandv\fR\|(3),
@@ -162,7 +171,7 @@ remctl protocol are available from its web page at
 <http://www.eyrie.org/~eagle/software/remctl/>.
 .SH "AUTHOR"
 .IX Header "AUTHOR"
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 .SH "COPYRIGHT AND LICENSE"
 .IX Header "COPYRIGHT AND LICENSE"
 Copyright 2007, 2009 The Board of Trustees of the Leland Stanford Junior
diff --git a/docs/api/remctl_error.pod b/docs/api/remctl_error.pod
index 15d9097..a76fa17 100644
--- a/docs/api/remctl_error.pod
+++ b/docs/api/remctl_error.pod
@@ -40,7 +40,7 @@ L<http://www.eyrie.org/~eagle/software/remctl/>.
 
 =head1 AUTHOR
 
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 
 =head1 COPYRIGHT AND LICENSE
 
diff --git a/docs/api/remctl_new.3 b/docs/api/remctl_new.3
index cc09189..914cd22 100644
--- a/docs/api/remctl_new.3
+++ b/docs/api/remctl_new.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.26)
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -38,6 +38,8 @@
 .    ds PI \(*p
 .    ds L" ``
 .    ds R" ''
+.    ds C`
+.    ds C'
 'br\}
 .\"
 .\" Escape single quotes in literal strings from groff's Unicode transform.
@@ -48,17 +50,24 @@
 .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
-.ie \nF \{\
-.    de IX
-.    tm Index:\\$1\t\\n%\t"\\$2"
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
 ..
-.    nr % 0
-.    rr F
-.\}
-.el \{\
-.    de IX
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
 .\}
+.rr rF
 .\"
 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
@@ -124,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_NEW 3"
-.TH REMCTL_NEW 3 "2013-08-14" "3.6" "remctl Library Reference"
+.TH REMCTL_NEW 3 "2014-01-06" "3.7" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -140,7 +149,7 @@ struct remctl *\fBremctl_new\fR(void);
 .IX Header "DESCRIPTION"
 \&\fIremctl_new()\fR creates a new remctl client.  The resulting remctl struct is
 opaque from the perspective of the caller, but should be the first
-argument to all subsequent calls into the remctl \s-1API\s0.  Normally, the next
+argument to all subsequent calls into the remctl \s-1API. \s0 Normally, the next
 call after \fIremctl_new()\fR would be \fIremctl_open()\fR to connect to a remote
 server.
 .PP
@@ -148,7 +157,7 @@ The resulting struct should be freed by calling \fIremctl_close()\fR.
 .SH "RETURN VALUE"
 .IX Header "RETURN VALUE"
 \&\fIremctl_new()\fR returns a pointer to an opaque remctl struct on success and
-\&\s-1NULL\s0 on failure.  If it returns \s-1NULL\s0, errno will be set to an appropriate
+\&\s-1NULL\s0 on failure.  If it returns \s-1NULL,\s0 errno will be set to an appropriate
 error code (normally \s-1ENOMEM\s0).
 .SH "SEE ALSO"
 .IX Header "SEE ALSO"
@@ -160,7 +169,7 @@ remctl protocol are available from its web page at
 <http://www.eyrie.org/~eagle/software/remctl/>.
 .SH "AUTHOR"
 .IX Header "AUTHOR"
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 .SH "COPYRIGHT AND LICENSE"
 .IX Header "COPYRIGHT AND LICENSE"
 Copyright 2007, 2009 The Board of Trustees of the Leland Stanford Junior
diff --git a/docs/api/remctl_new.pod b/docs/api/remctl_new.pod
index 970cfc9..c551ab7 100644
--- a/docs/api/remctl_new.pod
+++ b/docs/api/remctl_new.pod
@@ -38,7 +38,7 @@ L<http://www.eyrie.org/~eagle/software/remctl/>.
 
 =head1 AUTHOR
 
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 
 =head1 COPYRIGHT AND LICENSE
 
diff --git a/docs/api/remctl_noop.3 b/docs/api/remctl_noop.3
index 7535c7a..8e7b378 100644
--- a/docs/api/remctl_noop.3
+++ b/docs/api/remctl_noop.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.26)
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -38,6 +38,8 @@
 .    ds PI \(*p
 .    ds L" ``
 .    ds R" ''
+.    ds C`
+.    ds C'
 'br\}
 .\"
 .\" Escape single quotes in literal strings from groff's Unicode transform.
@@ -48,17 +50,24 @@
 .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
-.ie \nF \{\
-.    de IX
-.    tm Index:\\$1\t\\n%\t"\\$2"
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
 ..
-.    nr % 0
-.    rr F
-.\}
-.el \{\
-.    de IX
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
 .\}
+.rr rF
 .\"
 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
@@ -124,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_NOOP 3"
-.TH REMCTL_NOOP 3 "2013-08-14" "3.6" "remctl Library Reference"
+.TH REMCTL_NOOP 3 "2014-01-06" "3.7" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -163,7 +172,7 @@ remctl protocol are available from its web page at
 <http://www.eyrie.org/~eagle/software/remctl/>.
 .SH "AUTHOR"
 .IX Header "AUTHOR"
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 .SH "COPYRIGHT AND LICENSE"
 .IX Header "COPYRIGHT AND LICENSE"
 Copyright 2011 The Board of Trustees of the Leland Stanford Junior
diff --git a/docs/api/remctl_noop.pod b/docs/api/remctl_noop.pod
index 454212f..6055aa3 100644
--- a/docs/api/remctl_noop.pod
+++ b/docs/api/remctl_noop.pod
@@ -41,7 +41,7 @@ L<http://www.eyrie.org/~eagle/software/remctl/>.
 
 =head1 AUTHOR
 
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 
 =head1 COPYRIGHT AND LICENSE
 
diff --git a/docs/api/remctl_open.3 b/docs/api/remctl_open.3
index 8f37d72..9fe511e 100644
--- a/docs/api/remctl_open.3
+++ b/docs/api/remctl_open.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.26)
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -38,6 +38,8 @@
 .    ds PI \(*p
 .    ds L" ``
 .    ds R" ''
+.    ds C`
+.    ds C'
 'br\}
 .\"
 .\" Escape single quotes in literal strings from groff's Unicode transform.
@@ -48,17 +50,24 @@
 .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
-.ie \nF \{\
-.    de IX
-.    tm Index:\\$1\t\\n%\t"\\$2"
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
 ..
-.    nr % 0
-.    rr F
-.\}
-.el \{\
-.    de IX
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
 .\}
+.rr rF
 .\"
 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
@@ -124,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_OPEN 3"
-.TH REMCTL_OPEN 3 "2013-08-14" "3.6" "remctl Library Reference"
+.TH REMCTL_OPEN 3 "2014-01-06" "3.7" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -154,17 +163,17 @@ int \fBremctl_open_fd\fR(struct remctl *\fIr\fR, const char *\fIhost\fR,
 \&\fIremctl_open()\fR opens a \s-1TCP\s0 connection to the given \fIhost\fR on the given
 \&\fIport\fR and then authenticates using the remctl protocol and the service
 principal \fIprincipal\fR.  \fIr\fR is a remctl struct created via \fIremctl_new()\fR.
-\&\fIhost\fR must not be \s-1NULL\s0.  If \fIport\fR is 0, the library first attempts to
+\&\fIhost\fR must not be \s-1NULL. \s0 If \fIport\fR is 0, the library first attempts to
 connect to the registered port of 4373 and then tries the legacy port of
 4444 if that fails.  Future versions of the library will drop this
-fallback to 4444.  If \fIprincipal\fR is \s-1NULL\s0, a service principal of
+fallback to 4444.  If \fIprincipal\fR is \s-1NULL,\s0 a service principal of
 \&\f(CW\*(C`host/\f(CIhost\f(CW\*(C'\fR is used, with the realm determined by domain-realm
 mapping.
 .PP
 \&\fIremctl_open_addrinfo()\fR operates in the same manner as \fIremctl_open()\fR, but
 connects to the first usable address in \fIai\fR, which must be a list of
 results as returned by \fIgetaddrinfo\fR\|(3).  The \fIhost\fR is used only to form
-the default service principal, and may be \s-1NULL\s0 if \fIprincipal\fR is not \s-1NULL\s0.
+the default service principal, and may be \s-1NULL\s0 if \fIprincipal\fR is not \s-1NULL.\s0
 .PP
 \&\fIremctl_open_sockaddr()\fR is equivalent to \fIremctl_open_addrinfo()\fR with a
 single addrinfo structure specifying the use of \s-1TCP\s0 with socket address
@@ -192,10 +201,10 @@ control which ticket cache is used.
 the caller should call \fIremctl_error()\fR to retrieve the error message.
 .SH "CAVEATS"
 .IX Header "CAVEATS"
-If the \fIprincipal\fR argument to \fIremctl_open()\fR is \s-1NULL\s0, most GSS-API
+If the \fIprincipal\fR argument to \fIremctl_open()\fR is \s-1NULL,\s0 most GSS-API
 libraries will canonicalize the \fIhost\fR using \s-1DNS\s0 before deriving the
 principal name from it.  This means that when connecting to a remctl
-server via a \s-1CNAME\s0, \fIremctl_open()\fR will normally authenticate using a
+server via a \s-1CNAME,\s0 \fIremctl_open()\fR will normally authenticate using a
 principal based on the canonical name of the host instead of the specified
 \&\fIhost\fR parameter.  This behavior may cause problems if two consecutive
 \&\s-1DNS\s0 lookups of \fIhost\fR may return two different results, such as with some
@@ -237,7 +246,7 @@ remctl protocol are available from its web page at
 <http://www.eyrie.org/~eagle/software/remctl/>.
 .SH "AUTHOR"
 .IX Header "AUTHOR"
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 .SH "COPYRIGHT AND LICENSE"
 .IX Header "COPYRIGHT AND LICENSE"
 Copyright 2007, 2008, 2009 The Board of Trustees of the Leland Stanford
diff --git a/docs/api/remctl_open.pod b/docs/api/remctl_open.pod
index 9a3113a..912cf55 100644
--- a/docs/api/remctl_open.pod
+++ b/docs/api/remctl_open.pod
@@ -118,7 +118,7 @@ L<http://www.eyrie.org/~eagle/software/remctl/>.
 
 =head1 AUTHOR
 
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 
 =head1 COPYRIGHT AND LICENSE
 
diff --git a/docs/api/remctl_output.3 b/docs/api/remctl_output.3
index c23b4b2..9c7c221 100644
--- a/docs/api/remctl_output.3
+++ b/docs/api/remctl_output.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.26)
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -38,6 +38,8 @@
 .    ds PI \(*p
 .    ds L" ``
 .    ds R" ''
+.    ds C`
+.    ds C'
 'br\}
 .\"
 .\" Escape single quotes in literal strings from groff's Unicode transform.
@@ -48,17 +50,24 @@
 .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
-.ie \nF \{\
-.    de IX
-.    tm Index:\\$1\t\\n%\t"\\$2"
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
 ..
-.    nr % 0
-.    rr F
-.\}
-.el \{\
-.    de IX
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
 .\}
+.rr rF
 .\"
 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
@@ -124,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_OUTPUT 3"
-.TH REMCTL_OUTPUT 3 "2013-08-14" "3.6" "remctl Library Reference"
+.TH REMCTL_OUTPUT 3 "2014-01-06" "3.7" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -166,13 +175,13 @@ where the type field will have one of the following values:
 .Ve
 .PP
 A command rejected by the remctl server will return a single output token
-of type \s-1REMCTL_OUT_ERROR\s0.  A successful command will return zero or more
+of type \s-1REMCTL_OUT_ERROR.  A\s0 successful command will return zero or more
 \&\s-1REMCTL_OUT_OUTPUT\s0 tokens representing the output of the command followed
 by a \s-1REMCTL_OUT_STATUS\s0 token giving the exit status of the command.
 Therefore, for each command issued, the caller should call
 \&\fIremctl_command()\fR or \fIremctl_commandv()\fR and then call \fIremctl_output()\fR
 repeatedly to retrieve each output token until \fIremctl_output()\fR returns a
-token of type \s-1REMCTL_OUT_ERROR\s0 or \s-1REMCTL_OUT_STATUS\s0.
+token of type \s-1REMCTL_OUT_ERROR\s0 or \s-1REMCTL_OUT_STATUS.\s0
 .PP
 A \s-1REMCTL_OUT_OUTPUT\s0 token will have data in the data field, whose length
 is given by the length field.  The output stream will be given by the
@@ -220,7 +229,7 @@ remctl protocol are available from its web page at
 <http://www.eyrie.org/~eagle/software/remctl/>.
 .SH "AUTHOR"
 .IX Header "AUTHOR"
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 .SH "COPYRIGHT AND LICENSE"
 .IX Header "COPYRIGHT AND LICENSE"
 Copyright 2007, 2009 The Board of Trustees of the Leland Stanford Junior
diff --git a/docs/api/remctl_output.pod b/docs/api/remctl_output.pod
index eeabcab..98f69ba 100644
--- a/docs/api/remctl_output.pod
+++ b/docs/api/remctl_output.pod
@@ -94,7 +94,7 @@ L<http://www.eyrie.org/~eagle/software/remctl/>.
 
 =head1 AUTHOR
 
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 
 =head1 COPYRIGHT AND LICENSE
 
diff --git a/docs/api/remctl_set_ccache.3 b/docs/api/remctl_set_ccache.3
index ad5ad8f..ffdc8ea 100644
--- a/docs/api/remctl_set_ccache.3
+++ b/docs/api/remctl_set_ccache.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.26)
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -38,6 +38,8 @@
 .    ds PI \(*p
 .    ds L" ``
 .    ds R" ''
+.    ds C`
+.    ds C'
 'br\}
 .\"
 .\" Escape single quotes in literal strings from groff's Unicode transform.
@@ -48,17 +50,24 @@
 .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
-.ie \nF \{\
-.    de IX
-.    tm Index:\\$1\t\\n%\t"\\$2"
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
 ..
-.    nr % 0
-.    rr F
-.\}
-.el \{\
-.    de IX
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
 .\}
+.rr rF
 .\"
 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
@@ -124,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_SET_CCACHE 3"
-.TH REMCTL_SET_CCACHE 3 "2013-08-14" "3.6" "remctl Library Reference"
+.TH REMCTL_SET_CCACHE 3 "2014-01-06" "3.7" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -199,7 +208,7 @@ remctl protocol are available from its web page at
 <http://www.eyrie.org/~eagle/software/remctl/>.
 .SH "AUTHOR"
 .IX Header "AUTHOR"
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 .SH "COPYRIGHT AND LICENSE"
 .IX Header "COPYRIGHT AND LICENSE"
 Copyright 2011, 2013 The Board of Trustees of the Leland Stanford Junior
diff --git a/docs/api/remctl_set_ccache.pod b/docs/api/remctl_set_ccache.pod
index 2edbb36..cf791ae 100644
--- a/docs/api/remctl_set_ccache.pod
+++ b/docs/api/remctl_set_ccache.pod
@@ -77,7 +77,7 @@ L<http://www.eyrie.org/~eagle/software/remctl/>.
 
 =head1 AUTHOR
 
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 
 =head1 COPYRIGHT AND LICENSE
 
diff --git a/docs/api/remctl_set_source_ip.3 b/docs/api/remctl_set_source_ip.3
index 8d0bc47..66d910f 100644
--- a/docs/api/remctl_set_source_ip.3
+++ b/docs/api/remctl_set_source_ip.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.26)
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -38,6 +38,8 @@
 .    ds PI \(*p
 .    ds L" ``
 .    ds R" ''
+.    ds C`
+.    ds C'
 'br\}
 .\"
 .\" Escape single quotes in literal strings from groff's Unicode transform.
@@ -48,17 +50,24 @@
 .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
-.ie \nF \{\
-.    de IX
-.    tm Index:\\$1\t\\n%\t"\\$2"
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
 ..
-.    nr % 0
-.    rr F
-.\}
-.el \{\
-.    de IX
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
 .\}
+.rr rF
 .\"
 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
@@ -124,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_SET_SOURCE_IP 3"
-.TH REMCTL_SET_SOURCE_IP 3 "2013-08-14" "3.6" "remctl Library Reference"
+.TH REMCTL_SET_SOURCE_IP 3 "2014-01-06" "3.7" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -141,7 +150,7 @@ int \fBremctl_set_source_ip\fR(struct remctl *\fIr\fR, const char *\fIsource\fR)
 \&\fIremctl_set_source_ip()\fR sets the source \s-1IP\s0 address for subsequent calls to
 \&\fIremctl_open()\fR on the same struct remctl object.  Call this function before
 \&\fIremctl_open()\fR if remctl client connections need to come from a specific
-source \s-1IP\s0.
+source \s-1IP.\s0
 .PP
 The \fIsource\fR parameter may be an IPv4 or IPv6 address (assuming the host
 supports IPv6).
@@ -164,7 +173,7 @@ remctl protocol are available from its web page at
 <http://www.eyrie.org/~eagle/software/remctl/>.
 .SH "AUTHOR"
 .IX Header "AUTHOR"
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 .SH "COPYRIGHT AND LICENSE"
 .IX Header "COPYRIGHT AND LICENSE"
 Copyright 2011 The Board of Trustees of the Leland Stanford Junior
diff --git a/docs/api/remctl_set_source_ip.pod b/docs/api/remctl_set_source_ip.pod
index d832a0f..2de68c8 100644
--- a/docs/api/remctl_set_source_ip.pod
+++ b/docs/api/remctl_set_source_ip.pod
@@ -42,7 +42,7 @@ L<http://www.eyrie.org/~eagle/software/remctl/>.
 
 =head1 AUTHOR
 
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 
 =head1 COPYRIGHT AND LICENSE
 
diff --git a/docs/api/remctl_set_timeout.3 b/docs/api/remctl_set_timeout.3
index 5b177d0..0500a32 100644
--- a/docs/api/remctl_set_timeout.3
+++ b/docs/api/remctl_set_timeout.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.26)
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -38,6 +38,8 @@
 .    ds PI \(*p
 .    ds L" ``
 .    ds R" ''
+.    ds C`
+.    ds C'
 'br\}
 .\"
 .\" Escape single quotes in literal strings from groff's Unicode transform.
@@ -48,17 +50,24 @@
 .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
-.ie \nF \{\
-.    de IX
-.    tm Index:\\$1\t\\n%\t"\\$2"
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
 ..
-.    nr % 0
-.    rr F
-.\}
-.el \{\
-.    de IX
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
 .\}
+.rr rF
 .\"
 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
@@ -124,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_SET_TIMEOUT 3"
-.TH REMCTL_SET_TIMEOUT 3 "2013-08-14" "3.6" "remctl Library Reference"
+.TH REMCTL_SET_TIMEOUT 3 "2014-01-06" "3.7" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -165,7 +174,7 @@ remctl protocol are available from its web page at
 <http://www.eyrie.org/~eagle/software/remctl/>.
 .SH "AUTHOR"
 .IX Header "AUTHOR"
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 .SH "COPYRIGHT AND LICENSE"
 .IX Header "COPYRIGHT AND LICENSE"
 Copyright 2012 The Board of Trustees of the Leland Stanford Junior
diff --git a/docs/api/remctl_set_timeout.pod b/docs/api/remctl_set_timeout.pod
index a99bc9f..e9abeec 100644
--- a/docs/api/remctl_set_timeout.pod
+++ b/docs/api/remctl_set_timeout.pod
@@ -43,7 +43,7 @@ L<http://www.eyrie.org/~eagle/software/remctl/>.
 
 =head1 AUTHOR
 
-Russ Allbery <rra@stanford.edu>
+Russ Allbery <eagle@eyrie.org>
 
 =head1 COPYRIGHT AND LICENSE
 
diff --git a/docs/extending b/docs/extending
index eb701c1..2c2ede0 100644
--- a/docs/extending
+++ b/docs/extending
@@ -13,7 +13,7 @@ Introduction
     of additions.
 
     If you're considering extending remctl, please feel free to contact me
-    at rra@stanford.edu and let me know what you're planning and what
+    at eagle@eyrie.org and let me know what you're planning and what
     problem you're trying to solve.  I'm generally happy to offer advice
     and incorporate and maintain extensions in the base distribution, even
     if they're optional features that require external libraries to build.
diff --git a/docs/protocol.html b/docs/protocol.html
index cf0fb2b..e060017 100644
--- a/docs/protocol.html
+++ b/docs/protocol.html
@@ -1,218 +1,441 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en"><head><title>remctl Protocol: remctl: Remote Authenticated Command Service</title>
-<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
-<meta name="description" content="remctl: Remote Authenticated Command Service">
-<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
-<style type='text/css'><!--
-        body {
-                font-family: verdana, charcoal, helvetica, arial, sans-serif;
-                font-size: small; color: #000; background-color: #FFF;
-                margin: 2em;
-        }
-        h1, h2, h3, h4, h5, h6 {
-                font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
-                font-weight: bold; font-style: normal;
-        }
-        h1 { color: #900; background-color: transparent; text-align: right; }
-        h3 { color: #333; background-color: transparent; }
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 
-        td.RFCbug {
-                font-size: x-small; text-decoration: none;
-                width: 30px; height: 30px; padding-top: 2px;
-                text-align: justify; vertical-align: middle;
-                background-color: #000;
-        }
-        td.RFCbug span.RFC {
-                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
-                font-weight: bold; color: #666;
-        }
-        td.RFCbug span.hotText {
-                font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
-                font-weight: normal; text-align: center; color: #FFF;
-        }
+<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
+  <meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
 
-        table.TOCbug { width: 30px; height: 15px; }
-        td.TOCbug {
-                text-align: center; width: 30px; height: 15px;
-                color: #FFF; background-color: #900;
-        }
-        td.TOCbug a {
-                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
-                font-weight: bold; font-size: x-small; text-decoration: none;
-                color: #FFF; background-color: transparent;
-        }
+  <title>remctl: Remote Authenticated Command Service</title>
 
-        td.header {
-                font-family: arial, helvetica, sans-serif; font-size: x-small;
-                vertical-align: top; width: 33%;
-                color: #FFF; background-color: #666;
-        }
-        td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
-        td.author-text { font-size: x-small; }
+  <style type="text/css" title="Xml2Rfc (sans serif)">
+  /*<![CDATA[*/
+	  a {
+	  text-decoration: none;
+	  }
+	  a.smpl {
+	  color: black;
+	  }
+	  a:hover {
+	  text-decoration: underline;
+	  }
+	  a:active {
+	  text-decoration: underline;
+	  }
+	  address {
+	  margin-top: 1em;
+	  margin-left: 2em;
+	  font-style: normal;
+	  }
+	  body {
+	  color: black;
+	  font-family: verdana, helvetica, arial, sans-serif;
+	  font-size: 10pt;
+	  max-width: 55em;
+	  
+	  }
+	  cite {
+	  font-style: normal;
+	  }
+	  dd {
+	  margin-right: 2em;
+	  }
+	  dl {
+	  margin-left: 2em;
+	  }
+	
+	  ul.empty {
+	  list-style-type: none;
+	  }
+	  ul.empty li {
+	  margin-top: .5em;
+	  }
+	  dl p {
+	  margin-left: 0em;
+	  }
+	  dt {
+	  margin-top: .5em;
+	  }
+	  h1 {
+	  font-size: 14pt;
+	  line-height: 21pt;
+	  page-break-after: avoid;
+	  }
+	  h1.np {
+	  page-break-before: always;
+	  }
+	  h1 a {
+	  color: #333333;
+	  }
+	  h2 {
+	  font-size: 12pt;
+	  line-height: 15pt;
+	  page-break-after: avoid;
+	  }
+	  h3, h4, h5, h6 {
+	  font-size: 10pt;
+	  page-break-after: avoid;
+	  }
+	  h2 a, h3 a, h4 a, h5 a, h6 a {
+	  color: black;
+	  }
+	  img {
+	  margin-left: 3em;
+	  }
+	  li {
+	  margin-left: 2em;
+	  margin-right: 2em;
+	  }
+	  ol {
+	  margin-left: 2em;
+	  margin-right: 2em;
+	  }
+	  ol p {
+	  margin-left: 0em;
+	  }
+	  p {
+	  margin-left: 2em;
+	  margin-right: 2em;
+	  }
+	  pre {
+	  margin-left: 3em;
+	  background-color: lightyellow;
+	  padding: .25em;
+	  }
+	  pre.text2 {
+	  border-style: dotted;
+	  border-width: 1px;
+	  background-color: #f0f0f0;
+	  width: 69em;
+	  }
+	  pre.inline {
+	  background-color: white;
+	  padding: 0em;
+	  }
+	  pre.text {
+	  border-style: dotted;
+	  border-width: 1px;
+	  background-color: #f8f8f8;
+	  width: 69em;
+	  }
+	  pre.drawing {
+	  border-style: solid;
+	  border-width: 1px;
+	  background-color: #f8f8f8;
+	  padding: 2em;
+	  }
+	  table {
+	  margin-left: 2em;
+	  }
+	  table.tt {
+	  vertical-align: top;
+	  }
+	  table.full {
+	  border-style: outset;
+	  border-width: 1px;
+	  }
+	  table.headers {
+	  border-style: outset;
+	  border-width: 1px;
+	  }
+	  table.tt td {
+	  vertical-align: top;
+	  }
+	  table.full td {
+	  border-style: inset;
+	  border-width: 1px;
+	  }
+	  table.tt th {
+	  vertical-align: top;
+	  }
+	  table.full th {
+	  border-style: inset;
+	  border-width: 1px;
+	  }
+	  table.headers th {
+	  border-style: none none inset none;
+	  border-width: 1px;
+	  }
+	  table.left {
+	  margin-right: auto;
+	  }
+	  table.right {
+	  margin-left: auto;
+	  }
+	  table.center {
+	  margin-left: auto;
+	  margin-right: auto;
+	  }
+	  caption {
+	  caption-side: bottom;
+	  font-weight: bold;
+	  font-size: 9pt;
+	  margin-top: .5em;
+	  }
+	
+	  table.header {
+	  border-spacing: 1px;
+	  width: 95%;
+	  font-size: 10pt;
+	  color: white;
+	  }
+	  td.top {
+	  vertical-align: top;
+	  }
+	  td.topnowrap {
+	  vertical-align: top;
+	  white-space: nowrap; 
+	  }
+	  table.header td {
+	  background-color: gray;
+	  width: 50%;
+	  }
+	  table.header a {
+	  color: white;
+	  }
+	  td.reference {
+	  vertical-align: top;
+	  white-space: nowrap;
+	  padding-right: 1em;
+	  }
+	  thead {
+	  display:table-header-group;
+	  }
+	  ul.toc, ul.toc ul {
+	  list-style: none;
+	  margin-left: 1.5em;
+	  margin-right: 0em;
+	  padding-left: 0em;
+	  }
+	  ul.toc li {
+	  line-height: 150%;
+	  font-weight: bold;
+	  font-size: 10pt;
+	  margin-left: 0em;
+	  margin-right: 0em;
+	  }
+	  ul.toc li li {
+	  line-height: normal;
+	  font-weight: normal;
+	  font-size: 9pt;
+	  margin-left: 0em;
+	  margin-right: 0em;
+	  }
+	  li.excluded {
+	  font-size: 0pt;
+	  }
+	  ul p {
+	  margin-left: 0em;
+	  }
+	
+	  .comment {
+	  background-color: yellow;
+	  }
+	  .center {
+	  text-align: center;
+	  }
+	  .error {
+	  color: red;
+	  font-style: italic;
+	  font-weight: bold;
+	  }
+	  .figure {
+	  font-weight: bold;
+	  text-align: center;
+	  font-size: 9pt;
+	  }
+	  .filename {
+	  color: #333333;
+	  font-weight: bold;
+	  font-size: 12pt;
+	  line-height: 21pt;
+	  text-align: center;
+	  }
+	  .fn {
+	  font-weight: bold;
+	  }
+	  .hidden {
+	  display: none;
+	  }
+	  .left {
+	  text-align: left;
+	  }
+	  .right {
+	  text-align: right;
+	  }
+	  .title {
+	  color: #990000;
+	  font-size: 18pt;
+	  line-height: 18pt;
+	  font-weight: bold;
+	  text-align: center;
+	  margin-top: 36pt;
+	  }
+	  .vcardline {
+	  display: block;
+	  }
+	  .warning {
+	  font-size: 14pt;
+	  background-color: yellow;
+	  }
+	
+	
+	  @media print {
+	  .noprint {
+		display: none;
+	  }
+	
+	  a {
+		color: black;
+		text-decoration: none;
+	  }
+	
+	  table.header {
+		width: 90%;
+	  }
+	
+	  td.header {
+		width: 50%;
+		color: black;
+		background-color: white;
+		vertical-align: top;
+		font-size: 12pt;
+	  }
+	
+	  ul.toc a::after {
+		content: leader('.') target-counter(attr(href), page);
+	  }
+	
+	  ul.ind li li a {
+		content: target-counter(attr(href), page);
+	  }
+	
+	  .print2col {
+		column-count: 2;
+		-moz-column-count: 2;
+		column-fill: auto;
+	  }
+	  }
+	
+	  @page {
+	  @top-left {
+		   content: "Internet-Draft"; 
+	  } 
+	  @top-right {
+		   content: "December 2010"; 
+	  } 
+	  @top-center {
+		   content: "Abbreviated Title";
+	  } 
+	  @bottom-left {
+		   content: "Doe"; 
+	  } 
+	  @bottom-center {
+		   content: "Expires June 2011"; 
+	  } 
+	  @bottom-right {
+		   content: "[Page " counter(page) "]"; 
+	  } 
+	  }
+	
+	  @page:first { 
+		@top-left {
+		  content: normal;
+		}
+		@top-right {
+		  content: normal;
+		}
+		@top-center {
+		  content: normal;
+		}
+	  }
+  /*]]>*/
+  </style>
 
-        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
-        a.info {
-                /* This is the key. */
-                position: relative;
-                z-index: 24;
-                text-decoration: none;
-        }
-        a.info:hover {
-                z-index: 25;
-                color: #FFF; background-color: #900;
-        }
-        a.info span { display: none; }
-        a.info:hover span.info {
-                /* The span will display just on :hover state. */
-                display: block;
-                position: absolute;
-                font-size: smaller;
-                top: 2em; left: -5em; width: 15em;
-                padding: 2px; border: 1px solid #333;
-                color: #900; background-color: #EEE;
-                text-align: left;
-        }
+  <link href="#rfc.toc" rel="Contents"/>
+<link href="#rfc.section.1" rel="Chapter" title="1 Basic Packet Format"/>
+<link href="#rfc.section.2" rel="Chapter" title="2 Network Protocol (version 3)"/>
+<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Session Sequence"/>
+<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Message Format"/>
+<link href="#rfc.section.2.3" rel="Chapter" title="2.3 Protocol Version Negotiation"/>
+<link href="#rfc.section.2.4" rel="Chapter" title="2.4 MESSAGE_COMMAND"/>
+<link href="#rfc.section.2.5" rel="Chapter" title="2.5 MESSAGE_OUTPUT and MESSAGE_STATUS"/>
+<link href="#rfc.section.2.6" rel="Chapter" title="2.6 MESSAGE_ERROR"/>
+<link href="#rfc.section.2.7" rel="Chapter" title="2.7 MESSAGE_QUIT"/>
+<link href="#rfc.section.2.8" rel="Chapter" title="2.8 MESSAGE_NOOP"/>
+<link href="#rfc.section.3" rel="Chapter" title="3 Network Protocol (version 1)"/>
+<link href="#rfc.section.4" rel="Chapter" title="4 Security Considerations"/>
+<link href="#rfc.references" rel="Chapter" title="5 References"/>
+<link href="#rfc.appendix.A" rel="Chapter" title="A Acknowledgements"/>
+<link href="#rfc.appendix.B" rel="Chapter" title="B Additional License"/>
+<link href="#rfc.authors" rel="Chapter"/>
 
-        a { font-weight: bold; }
-        a:link    { color: #900; background-color: transparent; }
-        a:visited { color: #633; background-color: transparent; }
-        a:active  { color: #633; background-color: transparent; }
 
-        p { margin-left: 2em; margin-right: 2em; }
-        p.copyright { font-size: x-small; }
-        p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
-        table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
-        td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
+  <meta name="generator" content="xml2rfc version 2.4.3 - http://tools.ietf.org/tools/xml2rfc" />
+  <link rel="schema.dct" href="http://purl.org/dc/terms/" />
 
-        ol.text { margin-left: 2em; margin-right: 2em; }
-        ul.text { margin-left: 2em; margin-right: 2em; }
-        li      { margin-left: 3em; }
+  <meta name="dct.creator" content="Allbery, R." />
+  <meta name="dct.identifier" content="urn:ietf:id:draft-allbery-remctl-00" />
+  <meta name="dct.issued" scheme="ISO8601" content="2013-12" />
+  <meta name="dct.abstract" content="This document specifies the remctl wire protocol, used to send commands and arguments to a remote system and receive the results of executing that command.  The protocol uses GSS-API and Kerberos v5 for authentication, confidentiality, and integrity protection.  Both the current (version 3) protocol and the older version 1 protocol are described.  The version 1 protocol should only be implemented for backward compatibility." />
+  <meta name="description" content="This document specifies the remctl wire protocol, used to send commands and arguments to a remote system and receive the results of executing that command.  The protocol uses GSS-API and Kerberos v5 for authentication, confidentiality, and integrity protection.  Both the current (version 3) protocol and the older version 1 protocol are described.  The version 1 protocol should only be implemented for backward compatibility." />
 
-        /* RFC-2629 <spanx>s and <artwork>s. */
-        em     { font-style: italic; }
-        strong { font-weight: bold; }
-        dfn    { font-weight: bold; font-style: normal; }
-        cite   { font-weight: normal; font-style: normal; }
-        tt     { color: #036; }
-        tt, pre, pre dfn, pre em, pre cite, pre span {
-                font-family: "Courier New", Courier, monospace; font-size: small;
-        }
-        pre {
-                text-align: left; padding: 4px;
-                color: #000; background-color: #CCC;
-        }
-        pre dfn  { color: #900; }
-        pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
-        pre .key { color: #33C; font-weight: bold; }
-        pre .id  { color: #900; }
-        pre .str { color: #000; background-color: #CFF; }
-        pre .val { color: #066; }
-        pre .rep { color: #909; }
-        pre .oth { color: #000; background-color: #FCF; }
-        pre .err { background-color: #FCC; }
-
-        /* RFC-2629 <texttable>s. */
-        table.all, table.full, table.headers, table.none {
-                font-size: small; text-align: center; border-width: 2px;
-                vertical-align: top; border-collapse: collapse;
-        }
-        table.all, table.full { border-style: solid; border-color: black; }
-        table.headers, table.none { border-style: none; }
-        th {
-                font-weight: bold; border-color: black;
-                border-width: 2px 2px 3px 2px;
-        }
-        table.all th, table.full th { border-style: solid; }
-        table.headers th { border-style: none none solid none; }
-        table.none th { border-style: none; }
-        table.all td {
-                border-style: solid; border-color: #333;
-                border-width: 1px 2px;
-        }
-        table.full td, table.headers td, table.none td { border-style: none; }
-
-        hr { height: 1px; }
-        hr.insert {
-                width: 80%; border-style: none; border-width: 0;
-                color: #CCC; background-color: #CCC;
-        }
---></style>
 </head>
-<body>
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
-<tr><td class="header">remctl Protocol</td><td class="header">R. Allbery</td></tr>
-<tr><td class="header">&nbsp;</td><td class="header">Stanford University</td></tr>
-<tr><td class="header">&nbsp;</td><td class="header">October 2011</td></tr>
-</table></td></tr></table>
-<h1><br />remctl: Remote Authenticated Command Service</h1>
 
-<h3>Abstract</h3>
+<body>
 
-<p>This document specifies the remctl wire protocol, used to send
-      commands and arguments to a remote system and receive the results of
-      executing that command.  The protocol uses GSS-API and Kerberos v5
-      for authentication, confidentiality, and integrity protection.  Both
-      the current (version 3) protocol and the older version 1 protocol
-      are described.  The version 1 protocol should only be implemented
-      for backward compatibility.
-</p><a name="toc"></a><br /><hr />
-<h3>Table of Contents</h3>
-<p class="toc">
-<a href="#format">1.</a>&nbsp;
-Basic Packet Format<br />
-<a href="#proto3">2.</a>&nbsp;
-Network Protocol (version 3)<br />
-&nbsp;&nbsp;&nbsp;&nbsp;<a href="#packet">2.1.</a>&nbsp;
-Session Sequence<br />
-&nbsp;&nbsp;&nbsp;&nbsp;<a href="#messages">2.2.</a>&nbsp;
-Message Format<br />
-&nbsp;&nbsp;&nbsp;&nbsp;<a href="#negotiation">2.3.</a>&nbsp;
-Protocol Version Negotiation<br />
-&nbsp;&nbsp;&nbsp;&nbsp;<a href="#command">2.4.</a>&nbsp;
-MESSAGE_COMMAND<br />
-&nbsp;&nbsp;&nbsp;&nbsp;<a href="#output">2.5.</a>&nbsp;
-MESSAGE_OUTPUT and MESSAGE_STATUS<br />
-&nbsp;&nbsp;&nbsp;&nbsp;<a href="#error">2.6.</a>&nbsp;
-MESSAGE_ERROR<br />
-&nbsp;&nbsp;&nbsp;&nbsp;<a href="#quit">2.7.</a>&nbsp;
-MESSAGE_QUIT<br />
-&nbsp;&nbsp;&nbsp;&nbsp;<a href="#noop">2.8.</a>&nbsp;
-MESSAGE_NOOP<br />
-<a href="#proto1">3.</a>&nbsp;
-Network Protocol (version 1)<br />
-<a href="#security">4.</a>&nbsp;
-Security Considerations<br />
-<a href="#credits">Appendix&nbsp;A.</a>&nbsp;
-Acknowledgements<br />
-<a href="#license">Appendix&nbsp;B.</a>&nbsp;
-License<br />
-<a href="#rfc.authors">&#167;</a>&nbsp;
-Author's Address<br />
-</p>
-<br clear="all" />
+  <table class="header">
+    <tbody>
+    
+    	<tr>
+  <td class="left">Network Working Group</td>
+  <td class="right">R. Allbery</td>
+</tr>
+<tr>
+  <td class="left">Internet-Draft</td>
+  <td class="right">Stanford University</td>
+</tr>
+<tr>
+  <td class="left">Intended status: Informational</td>
+  <td class="right">December 2013</td>
+</tr>
+<tr>
+  <td class="left">Expires: June 4, 2014</td>
+  <td class="right"></td>
+</tr>
 
-<a name="format"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.1"></a><h3>1.&nbsp;
-Basic Packet Format</h3>
+    	
+    </tbody>
+  </table>
 
-<p>The remctl network protocol consists of data packets sent from a
-      client to a server or a server to a client over a TCP connection.
-      The remctl protocol may be used over any port, but the
-      IANA-registered port and the RECOMMENDED default for the protocol is
-      4373.  Each data packet has the following format:
-</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+  <p class="title">remctl: Remote Authenticated Command Service<br />
+  <span class="filename">draft-allbery-remctl-00</span></p>
+  
+  <h1 id="rfc.abstract">
+  <a href="#rfc.abstract">Abstract</a>
+</h1>
+<p>This document specifies the remctl wire protocol, used to send commands and arguments to a remote system and receive the results of executing that command.  The protocol uses GSS-API and Kerberos v5 for authentication, confidentiality, and integrity protection.  Both the current (version 3) protocol and the older version 1 protocol are described.  The version 1 protocol should only be implemented for backward compatibility.</p>
+<h1 id="rfc.status">
+  <a href="#rfc.status">Status of This Memo</a>
+</h1>
+<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
+<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).  Note that other groups may also distribute working documents as Internet-Drafts.  The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
+<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.  It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
+<p>This Internet-Draft will expire on June 4, 2014.</p>
+<h1 id="rfc.copyrightnotice">
+  <a href="#rfc.copyrightnotice">Copyright Notice</a>
+</h1>
+<p>Copyright (c) 2013 IETF Trust and the persons identified as the document authors.  All rights reserved.</p>
+<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document.  Please review these documents carefully, as they describe your rights and restrictions with respect to this document.  Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
+<h1 id="rfc.section.1"><a href="#rfc.section.1">1.</a> <a href="#format" id="format">Basic Packet Format</a></h1>
+<p id="rfc.section.1.p.1">The remctl network protocol consists of data packets sent from a client to a server or a server to a client over a TCP connection.  The remctl protocol may be used over any port, but the IANA-registered port and the RECOMMENDED default for the protocol is 4373.  Each data packet has the following format:</p>
+<pre>
     1 octet     flags
     4 octets    length
     &lt;length&gt;    data payload
-</pre></div>
-<p>The total size of each token, including the five octet prefix,
-      MUST NOT be larger than 1,048,576 octets (1MB).
-</p>
-<p>The flag octet contains one or more of the following
-        values, combined with binary xor:
-</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+        </pre>
+<p id="rfc.section.1.p.2">The total size of each token, including the five octet prefix, MUST NOT be larger than 1,048,576 octets (1MB).</p>
+<p>The flag octet contains one or more of the following values, combined with binary xor:</p>
+<pre>
     0x01        TOKEN_NOOP
     0x02        TOKEN_CONTEXT
     0x04        TOKEN_DATA
@@ -220,109 +443,34 @@ Basic Packet Format</h3>
     0x10        TOKEN_CONTEXT_NEXT
     0x20        TOKEN_SEND_MIC
     0x40        TOKEN_PROTOCOL
-</pre></div>
-<p>Only TOKEN_CONTEXT, TOKEN_CONTEXT_NEXT, TOKEN_DATA, and
-        TOKEN_PROTOCOL are used for packets for version 2 and of the
-        protocol.  The other flags are used only with the legacy version 1
-        protocol.
-</p>
-<p>The length field is a four-octet length in network byte order,
-      specifying the number of octets in the following data payload.
-</p>
-<p>The data payload is empty, the results of gss_accept_sec_context,
-      the results of gss_init_sec_context, or a data payload protected
-      with gss_wrap.  The length of the data passed to gss_wrap MUST NOT
-      be larger than 65,536 octets (64KB), even if the underlying Kerberos
-      implementation supports longer input buffers.
-</p>
-<a name="proto3"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.2"></a><h3>2.&nbsp;
-Network Protocol (version 3)</h3>
+        </pre>
+<p>Only TOKEN_CONTEXT, TOKEN_CONTEXT_NEXT, TOKEN_DATA, and TOKEN_PROTOCOL are used for packets for version 2 and of the protocol.  The other flags are used only with the legacy version 1 protocol.</p>
+<p id="rfc.section.1.p.3">The length field is a four-octet length in network byte order, specifying the number of octets in the following data payload.</p>
+<p id="rfc.section.1.p.4">The data payload is empty, the results of gss_accept_sec_context, the results of gss_init_sec_context, or a data payload protected with gss_wrap.  The length of the data passed to gss_wrap MUST NOT be larger than 65,536 octets (64KB), even if the underlying Kerberos implementation supports longer input buffers.</p>
+<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#proto3" id="proto3">Network Protocol (version 3)</a></h1>
+<h1 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1.</a> <a href="#packet" id="packet">Session Sequence</a></h1>
+<p id="rfc.section.2.1.p.1">A remctl connection is always initiated by a client opening a TCP connection to a server.  The protocol then proceeds as follows: </p>
 
-<a name="packet"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.2.1"></a><h3>2.1.&nbsp;
-Session Sequence</h3>
+<ol>
+  <li>Client sends message with an empty payload and flags TOKEN_NOOP, TOKEN_CONTEXT_NEXT, and TOKEN_PROTOCOL (0x51).  If the client doesn't include TOKEN_PROTOCOL, it is speaking the version 1 protocol, and the server MUST either drop the connection or fall back to the version 1 protocol.  This initial message is useless in a pure version 2 protocol world and is done only for backward compatibility with the version 1 protocol.</li>
+  <li>Client calls gss_init_sec_context and replies with the results and TOKEN_CONTEXT and TOKEN_PROTOCOL (0x42).  The client MUST pass GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG as requested flags and SHOULD pass GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG.</li>
+  <li>Server replies with the results of gss_accept_sec_context and flags TOKEN_CONTEXT and TOKEN_PROTOCOL (0x42).  If the server doesn't include TOKEN_PROTOCOL in the flags, it is speaking the version 1 protocol, and the client MUST either drop the connection or fall back to the version 1 protocol.</li>
+  <li>Client passes data to gss_init_sec_context and replies with the results and TOKEN_CONTEXT and TOKEN_PROTOCOL (0x42).  The client must pass GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG as requested flags and SHOULD pass GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG.</li>
+  <li>Server and client repeat, passing in the payload from the last packet from the other side, for as long as GSS-API indicates that continuation is required.  If either side drops TOKEN_PROTOCOL from the flags, it is an considered an error and the connect MUST be dropped.  (This could be a down-negotiation attack.)  After the establishment of the security context, both client and server MUST confirm that GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG are set in the resulting security context and MUST immediately close the connection if this is not the case.</li>
+  <li>After the security context has been established, the client and server exchange commands and responses as described below.  All commands are sent with flags TOKEN_DATA and TOKEN_PROTOCOL (0x44) and the data payload of all packets is protected with gss_wrap.  The conf_req_flag parameter of gss_wrap MUST be set to non-zero, requesting both confidentiality and integrity services.</li>
+</ol>
 
-<p>A remctl connection is always initiated by a client opening a
-        TCP connection to a server.  The protocol then proceeds as
-        follows:
-          </p>
-<ol class="text">
-<li>Client sends message with an empty payload and flags
-            TOKEN_NOOP, TOKEN_CONTEXT_NEXT, and TOKEN_PROTOCOL (0x51).  If
-            the client doesn't include TOKEN_PROTOCOL, it is speaking the
-            version 1 protocol, and the server MUST either drop the
-            connection or fall back to the version 1 protocol.  This
-            initial message is useless in a pure version 2 protocol world
-            and is done only for backward compatibility with the version 1
-            protocol.
-</li>
-<li>Client calls gss_init_sec_context and replies with the
-            results and TOKEN_CONTEXT and TOKEN_PROTOCOL (0x42).  The
-            client MUST pass GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and
-            GSS_C_INTEG_FLAG as requested flags and SHOULD pass
-            GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG.
-</li>
-<li>Server replies with the results of gss_accept_sec_context
-            and flags TOKEN_CONTEXT and TOKEN_PROTOCOL (0x42).  If the
-            server doesn't include TOKEN_PROTOCOL in the flags, it is
-            speaking the version 1 protocol, and the client MUST either
-            drop the connection or fall back to the version 1
-            protocol.
-</li>
-<li>Client passes data to gss_init_sec_context and replies with
-            the results and TOKEN_CONTEXT and TOKEN_PROTOCOL (0x42).  The
-            client must pass GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and
-            GSS_C_INTEG_FLAG as requested flags and SHOULD pass
-            GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG.
-</li>
-<li>Server and client repeat, passing in the payload from the
-            last packet from the other side, for as long as GSS-API
-            indicates that continuation is required.  If either side drops
-            TOKEN_PROTOCOL from the flags, it is an considered an error
-            and the connect MUST be dropped.  (This could be a
-            down-negotiation attack.)  After the establishment of the
-            security context, both client and server MUST confirm that
-            GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG are
-            set in the resulting security context and MUST immediately
-            close the connection if this is not the case.
-</li>
-<li>After the security context has been established, the client
-            and server exchange commands and responses as described below.
-            All commands are sent with flags TOKEN_DATA and TOKEN_PROTOCOL
-            (0x44) and the data payload of all packets is protected with
-            gss_wrap.  The conf_req_flag parameter of gss_wrap MUST be set
-            to non-zero, requesting both confidentiality and integrity
-            services.
-</li>
-</ol><p>
-        
-</p>
-<a name="messages"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.2.2"></a><h3>2.2.&nbsp;
-Message Format</h3>
-
-<p>All client and server messages will use the following format
-        inside the data payload.  This is the format of the message before
-        passing it to gss_wrap for confidentiality and integrity
-        protection.
-</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+<p> </p>
+<h1 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2.</a> <a href="#messages" id="messages">Message Format</a></h1>
+<p id="rfc.section.2.2.p.1">All client and server messages will use the following format inside the data payload.  This is the format of the message before passing it to gss_wrap for confidentiality and integrity protection.</p>
+<pre>
     1 octet     protocol version
     1 octet     message type
     &lt;command-specific data&gt;
-</pre></div>
-<p>The protocol version sent for all messages should be 2 with the
-        exception of MESSAGE_NOOP, which should have a protocol version of
-        3.  The version 1 protocol does not use this message format, and
-        therefore a protocol version of 1 is invalid.  See below for
-        protocol version negotiation.
-</p>
-<p>The message type is one of the following
-          constants:
-</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+          </pre>
+<p id="rfc.section.2.2.p.2">The protocol version sent for all messages should be 2 with the exception of MESSAGE_NOOP, which should have a protocol version of 3.  The version 1 protocol does not use this message format, and therefore a protocol version of 1 is invalid.  See below for protocol version negotiation.</p>
+<p>The message type is one of the following constants:</p>
+<pre>
     1   MESSAGE_COMMAND
     2   MESSAGE_QUIT
     3   MESSAGE_OUTPUT
@@ -330,166 +478,56 @@ Message Format</h3>
     5   MESSAGE_ERROR
     6   MESSAGE_VERSION
     7   MESSAGE_NOOP
-</pre></div>
-<p>The first two message types are client messages and MUST NOT be
-        sent by the server.  The remaining message types are server messages
-        and MUST NOT by sent by the client.
-</p>
-<p>All of these message types were introduced in protocol version
-        2 except for MESSAGE_NOOP, which is a protocol version 3
-        message.
-</p>
-<a name="negotiation"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.2.3"></a><h3>2.3.&nbsp;
-Protocol Version Negotiation</h3>
-
-<p>If the server ever receives a message from a client that claims a
-        protocol version higher than the server supports, the server MUST
-        otherwise ignore the contents of the message and SHOULD respond with
-        a message type of MESSAGE_VERSION and the following message
-        payload:
-</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+          </pre>
+<p id="rfc.section.2.2.p.3">The first two message types are client messages and MUST NOT be sent by the server.  The remaining message types are server messages and MUST NOT by sent by the client.</p>
+<p id="rfc.section.2.2.p.4">All of these message types were introduced in protocol version 2 except for MESSAGE_NOOP, which is a protocol version 3 message.</p>
+<h1 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3.</a> <a href="#negotiation" id="negotiation">Protocol Version Negotiation</a></h1>
+<p id="rfc.section.2.3.p.1">If the server ever receives a message from a client that claims a protocol version higher than the server supports, the server MUST otherwise ignore the contents of the message and SHOULD respond with a message type of MESSAGE_VERSION and the following message payload:</p>
+<pre>
     1 octet     highest supported version
-</pre></div>
-<p>The client MUST then either send only messages supported at
-        that protocol version or lower or send MESSAGE_QUIT and close the
-        connection.
-</p>
-<p>Currently, there are only two meaningful values for the highest
-        supported version: 3, which indicates everything in this
-        specification is supported, or 2, which indicates that everything
-        except MESSAGE_NOOP is supported.
-</p>
-<a name="command"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.2.4"></a><h3>2.4.&nbsp;
-MESSAGE_COMMAND</h3>
-
-<p>Most client messages will be of type MESSAGE_COMMAND, which has
-        the following format:
-</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+          </pre>
+<p id="rfc.section.2.3.p.2">The client MUST then either send only messages supported at that protocol version or lower or send MESSAGE_QUIT and close the connection.</p>
+<p id="rfc.section.2.3.p.3">Currently, there are only two meaningful values for the highest supported version: 3, which indicates everything in this specification is supported, or 2, which indicates that everything except MESSAGE_NOOP is supported.</p>
+<h1 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4.</a> <a href="#command" id="command">MESSAGE_COMMAND</a></h1>
+<p id="rfc.section.2.4.p.1">Most client messages will be of type MESSAGE_COMMAND, which has the following format:</p>
+<pre>
     1 octet     keep-alive flag
     1 octet     continue status
     4 octets    number of arguments
     4 octets    argument length
     &lt;length&gt;    argument
     ...
-</pre></div>
-<p>If the keep-alive flag is 0, the server SHOULD close the
-        connection after processing the command.  If it is 1, the server
-        SHOULD leave the connection open (up to a timeout period) and wait
-        for more commands.  This is similar to HTTP keep-alive.
-</p>
-<p>If the continue status is 1, it indicates that there is more
-        data coming.  The server should accept the data sent, buffer or
-        process it, and wait for additional messages before responding.
-        If the the continue status is 2, it indicates that this message is
-        logically a part of the previous message (which MUST have had a
-        continue status of 1 or 2) and still has more data coming.  If the
-        continue status is 3, it says that this message is logically part
-        of the previous message, like 2, but it also says that this is the
-        end of the command.
-</p>
-<p>A continuation of a message starts with the keep-alive flag and
-        continue status and then the next chunk of data.  To reconstruct a
-        continued message, remove the first two octets from each chunk and
-        concatenate the pieces together.  The result is the portion of a
-        MESSAGE_COMMAND starting with the number of arguments.  Messages
-        may be broken into multiple MESSAGE_COMMANDs even in the middle of
-        the number of arguments or an argument length.  In other words,
-        the first three octets of the number of arguments could be in the
-        first MESSAGE_COMMAND (with continue status 1) and the last octet
-        would then be in the next MESSAGE_COMMAND (with continue status 2
-        or 3).
-</p>
-<p>For as long as the continue status is 1 or 2, the next message
-        from the client MUST be either another MESSAGE_COMMAND with a
-        continue status of 2 or 3 or a MESSAGE_QUIT.  In other words,
-        other message types MUST NOT be intermixed with continued
-        commands, but MESSAGE_QUIT may be sent by the client in the middle
-        of a continued command to abort that command.  If the server
-        receives MESSAGE_QUIT from the client before receiving a
-        MESSAGE_COMMAND with a status of 3 (indicating the end of the
-        command), the command MUST be discarded and not executed.
-</p>
-<p>If a client sends an invalid sequence of MESSAGE_COMMAND
-        messages that violate the continuation rules described above, the
-        server SHOULD reply with a MESSAGE_ERROR message, generally with
-        either ERROR_BAD_TOKEN, ERROR_UNKNOWN_MESSAGE, ERROR_BAD_COMMAND,
-        or ERROR_UNEXPECTED_MESSAGE error codes.  It MUST discard the
-        partial command without acting on it.  The client cannot correct
-        an error in a continued MESSAGE_COMMAND stream by resending the
-        previous part.  It MUST start again at the beginning with a
-        MESSAGE_COMMAND with a continue status of 0 or 1.
-</p>
-<p>Number of arguments is a four-octet number in network byte
-        order that gives the total number of command arguments.  For each
-        argument, there is then a length and argument data pair, where the
-        length is a four-octet number in network byte order indicating the
-        number of octets of data in the following argument.  Argument
-        length may be 0.  Commands with no arguments are permitted by the
-        protocol.
-</p>
-<p>Servers may impose limits on the number of arguments and the
-        size of argument data to limit resource usage.  If the client
-        message exceeds one of those limits, the server MUST respond with
-        MESSAGE_ERROR with an error code of ERROR_TOOMANY_ARGS or
-        ERROR_TOOMUCH_DATA as appropriate.
-</p>
-<a name="output"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.2.5"></a><h3>2.5.&nbsp;
-MESSAGE_OUTPUT and MESSAGE_STATUS</h3>
-
-<p>The server response to MESSAGE_COMMAND is zero or more
-        MESSAGE_OUTPUT messages followed by either a MESSAGE_STATUS or a
-        MESSAGE_ERROR response.  Each MESSAGE_OUTPUT message has the
-        following format:
-</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+          </pre>
+<p id="rfc.section.2.4.p.2">If the keep-alive flag is 0, the server SHOULD close the connection after processing the command.  If it is 1, the server SHOULD leave the connection open (up to a timeout period) and wait for more commands.  This is similar to HTTP keep-alive.</p>
+<p id="rfc.section.2.4.p.3">If the continue status is 1, it indicates that there is more data coming.  The server should accept the data sent, buffer or process it, and wait for additional messages before responding.  If the the continue status is 2, it indicates that this message is logically a part of the previous message (which MUST have had a continue status of 1 or 2) and still has more data coming.  If the continue status is 3, it says that this message is logically part of the previous message, like 2, but it also says that this is the end of the command.</p>
+<p id="rfc.section.2.4.p.4">A continuation of a message starts with the keep-alive flag and continue status and then the next chunk of data.  To reconstruct a continued message, remove the first two octets from each chunk and concatenate the pieces together.  The result is the portion of a MESSAGE_COMMAND starting with the number of arguments.  Messages may be broken into multiple MESSAGE_COMMANDs even in the middle of the number of arguments or an argument length.  In other words, the first three octets of the number of arguments could be in the first MESSAGE_COMMAND (with continue status 1) and the last octet would then be in the next MESSAGE_COMMAND (with continue status 2 or 3).</p>
+<p id="rfc.section.2.4.p.5">For as long as the continue status is 1 or 2, the next message from the client MUST be either another MESSAGE_COMMAND with a continue status of 2 or 3 or a MESSAGE_QUIT.  In other words, other message types MUST NOT be intermixed with continued commands, but MESSAGE_QUIT may be sent by the client in the middle of a continued command to abort that command.  If the server receives MESSAGE_QUIT from the client before receiving a MESSAGE_COMMAND with a status of 3 (indicating the end of the command), the command MUST be discarded and not executed.</p>
+<p id="rfc.section.2.4.p.6">If a client sends an invalid sequence of MESSAGE_COMMAND messages that violate the continuation rules described above, the server SHOULD reply with a MESSAGE_ERROR message, generally with either ERROR_BAD_TOKEN, ERROR_UNKNOWN_MESSAGE, ERROR_BAD_COMMAND, or ERROR_UNEXPECTED_MESSAGE error codes.  It MUST discard the partial command without acting on it.  The client cannot correct an error in a continued MESSAGE_COMMAND stream by resending the previous part.  It MUST start again at the beginning with a MESSAGE_COMMAND with a continue status of 0 or 1.</p>
+<p id="rfc.section.2.4.p.7">Number of arguments is a four-octet number in network byte order that gives the total number of command arguments.  For each argument, there is then a length and argument data pair, where the length is a four-octet number in network byte order indicating the number of octets of data in the following argument.  Argument length may be 0.  Commands with no arguments are permitted by the protocol.</p>
+<p id="rfc.section.2.4.p.8">Servers may impose limits on the number of arguments and the size of argument data to limit resource usage.  If the client message exceeds one of those limits, the server MUST respond with MESSAGE_ERROR with an error code of ERROR_TOOMANY_ARGS or ERROR_TOOMUCH_DATA as appropriate.</p>
+<h1 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5.</a> <a href="#output" id="output">MESSAGE_OUTPUT and MESSAGE_STATUS</a></h1>
+<p id="rfc.section.2.5.p.1">The server response to MESSAGE_COMMAND is zero or more MESSAGE_OUTPUT messages followed by either a MESSAGE_STATUS or a MESSAGE_ERROR response.  Each MESSAGE_OUTPUT message has the following format:</p>
+<pre>
     1 octet     output stream
     4 octets    output length
     &lt;length&gt;    output
-</pre></div>
-<p>The output stream is either 1 for standard output or 2 for
-        standard error.  Output length is a four-octet number in network
-        byte order that specifies the length of the following output
-        data.
-</p>
-<p>The MESSAGE_STATUS message has the following format:
-</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+          </pre>
+<p id="rfc.section.2.5.p.2">The output stream is either 1 for standard output or 2 for standard error.  Output length is a four-octet number in network byte order that specifies the length of the following output data.</p>
+<p id="rfc.section.2.5.p.3">The MESSAGE_STATUS message has the following format:</p>
+<pre>
     1 octet     exit status
-</pre></div>
-<p>MESSAGE_STATUS indicates the command has finished and returns
-        the final exit stauts of the command.  Exit status is 0 for
-        success and non-zero for failure, where the meaning of non-zero
-        exit statuses is left to the application to define.  (This is
-        identical to a Unix command exit status.)
-</p>
-<p>Unless the MESSAGE_COMMAND message from the client had the
-        keep-alive flag set to 1, the server MUST close the network
-        connection immediately after sending the MESSAGE_STATUS response
-        message.
-</p>
-<a name="error"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.2.6"></a><h3>2.6.&nbsp;
-MESSAGE_ERROR</h3>
-
-<p>At any point before sending MESSAGE_STATUS, the server may
-        respond with MESSAGE_ERROR if some error occurred.  This can be
-        the first response after a MESSAGE_COMMAND, or it may be sent
-        after one or more MESSAGE_OUTPUT messages.  The format of
-        MESSAGE_ERROR is as follows:
-</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+          </pre>
+<p id="rfc.section.2.5.p.4">MESSAGE_STATUS indicates the command has finished and returns the final exit stauts of the command.  Exit status is 0 for success and non-zero for failure, where the meaning of non-zero exit statuses is left to the application to define.  (This is identical to a Unix command exit status.)</p>
+<p id="rfc.section.2.5.p.5">Unless the MESSAGE_COMMAND message from the client had the keep-alive flag set to 1, the server MUST close the network connection immediately after sending the MESSAGE_STATUS response message.</p>
+<h1 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6.</a> <a href="#error" id="error">MESSAGE_ERROR</a></h1>
+<p id="rfc.section.2.6.p.1">At any point before sending MESSAGE_STATUS, the server may respond with MESSAGE_ERROR if some error occurred.  This can be the first response after a MESSAGE_COMMAND, or it may be sent after one or more MESSAGE_OUTPUT messages.  The format of MESSAGE_ERROR is as follows:</p>
+<pre>
     4 octets    error code
     4 octets    message length
     &lt;length&gt;    error message
-</pre></div>
-<p>The error code is a four-octet number in network byte order
-        indicating the type of error.  The error code may be one of the
-        following values:
-</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+          </pre>
+<p id="rfc.section.2.6.p.2">The error code is a four-octet number in network byte order indicating the type of error.  The error code may be one of the following values:</p>
+<pre>
     1  ERROR_INTERNAL           Internal server failure
     2  ERROR_BAD_TOKEN          Invalid format in token
     3  ERROR_UNKNOWN_MESSAGE    Unknown message type
@@ -499,192 +537,99 @@ MESSAGE_ERROR</h3>
     7  ERROR_TOOMANY_ARGS       Argument count exceeds server limit
     8  ERROR_TOOMUCH_DATA       Argument size exceeds server limit
     9  ERROR_UNEXPECTED_MESSAGE Message type not valid now
-</pre></div>
-<p>Additional error codes may be added without changing the
-        version of the remctl protocol, so clients MUST accept error codes
-        other than the ones above.
-</p>
-<p>The message length is a four-octet number in network byte order
-        that specifies the length in octets of the following error
-        message.  The error message is a free-form informational message
-        intended for human consumption and MUST NOT be interpreted by an
-        automated process.  Software should instead use the error
-        code.
-</p>
-<p>Unless the MESSAGE_COMMAND message from the client had the
-        keep-alive flag set to 1, the server MUST close the network
-        connection immediately after sending the MESSAGE_ERROR response
-        message.  Otherwise, the server SHOULD still honor that flag,
-        although the server MAY terminate the connection after an
-        unreasonable number of errors.
-</p>
-<a name="quit"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.2.7"></a><h3>2.7.&nbsp;
-MESSAGE_QUIT</h3>
+          </pre>
+<p id="rfc.section.2.6.p.3">Additional error codes may be added without changing the version of the remctl protocol, so clients MUST accept error codes other than the ones above.</p>
+<p id="rfc.section.2.6.p.4">The message length is a four-octet number in network byte order that specifies the length in octets of the following error message.  The error message is a free-form informational message intended for human consumption and MUST NOT be interpreted by an automated process.  Software should instead use the error code.</p>
+<p id="rfc.section.2.6.p.5">Unless the MESSAGE_COMMAND message from the client had the keep-alive flag set to 1, the server MUST close the network connection immediately after sending the MESSAGE_ERROR response message.  Otherwise, the server SHOULD still honor that flag, although the server MAY terminate the connection after an unreasonable number of errors.</p>
+<h1 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7.</a> <a href="#quit" id="quit">MESSAGE_QUIT</a></h1>
+<p id="rfc.section.2.7.p.1">MESSAGE_QUIT is a way of terminating the connection cleanly if the client asked for keep-alive and then decided not to use it.  There is no message body.  Upon receiving this message, the server MUST immediately close the connection.</p>
+<h1 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8.</a> <a href="#noop" id="noop">MESSAGE_NOOP</a></h1>
+<p id="rfc.section.2.8.p.1">MESSAGE_NOOP provides a way for a client to keep the connection open to a remctl server, including through firewall session timeouts and similar network constraints that require periodic activity, without sending new commands.  There is no body.  When the client sends a MESSAGE_NOOP message, the server replies with a MESSAGE_NOOP message.</p>
+<p id="rfc.section.2.8.p.2">Note that MESSAGE_NOOP was introduced in protocol version 3 and therefore should be marked accordingly.  Clients should be prepared for older servers to reply with MESSAGE_VERSION instead of MESSAGE_NOOP.</p>
+<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#proto1" id="proto1">Network Protocol (version 1)</a></h1>
+<p id="rfc.section.3.p.1">The old network protocol supported only 64KB of data payload, only a single command and response, and had some additional unnecessary protocol components.  It SHOULD NOT be used by clients, but MAY be supported by servers for backward compatibility.  It is recognized by the server and client by the lack of TOKEN_PROTOCOL in the flags of the initial security context negotiation.</p>
+<p id="rfc.section.3.p.2">The old protocol always uses the following steps: </p>
+
+<ol>
+  <li>Client opens TCP connection to server.</li>
+  <li>Client sends message with flags TOKEN_NOOP and TOKEN_CONTEXT_NEXT and an empty payload.</li>
+  <li>Client calls gss_init_sec_context and sends message with the results and flags TOKEN_CONTEXT.  The client MUST pass GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG as requested flags and SHOULD pass GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG, although the version one protocol does not check the results of this negotiation.</li>
+  <li>Server replies with the results of gss_accept_sec_context and flags TOKEN_CONTEXT.</li>
+  <li>Client calls gss_init_sec_context again with the data from the server and replies with the results and flags TOKEN_CONTEXT, using the same requested flags as described above.</li>
+  <li>Server and client repeat, passing in the payload from the last packet from the other side, for as long as GSS-API indicates that continuation is required.  Each of these packets have only TOKEN_CONTEXT set in the flags.</li>
+  <li>Client sends command with flags TOKEN_DATA and TOKEN_SEND_MIC and the following payload format:  four-octet number of arguments, and then for each argument, a four-octet length and then the argument value.  All numbers are in network type order.  The payload MUST be protected with gss_wrap and the conf_req_flag parameter of gss_wrap MUST be set to non-zero, requesting both confidentiality and integrity services.</li>
+  <li>Server accepts and decrypts data, generates a MIC with gss_get_mic, and sends the MIC back to the client with flags TOKEN_MIC.  This is the only packet that isn't encrypted with gss_wrap.  Client receives and then SHOULD verify this MIC.</li>
+  <li>Server runs the command, collects the output, and sends the output back with flags TOKEN_DATA and the following payload format:  four-octet exit status, four-octet data length, data.  All numbers are in network byte order.  The exit status is 0 if there were no errors and non-zero otherwise, where the meaning of non-zero values are defined by the application.  The payload MUST be protected with gss_wrap with a conf_req_flag set to non-zero.</li>
+  <li>Server and client close connection.</li>
+</ol>
+
+<p> </p>
+<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#security" id="security">Security Considerations</a></h1>
+<p id="rfc.section.4.p.1">It would be preferrable to insist on replay and sequence protection (GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG) for all contexts, but some older Kerberos GSS-API implementations don't support this and hence it is not mandatory in the protocol.  Clients SHOULD always request replay and sequence protection, however, and servers MAY require such protection be negotiated.</p>
+<p id="rfc.section.4.p.2">The old protocol doesn't provide integrity protection for the flags, but since it always follows the same fixed sequence of operations, this should pose no security concerns in practice.  The new protocol only uses the flag field outside of the encrypted section of the packet for initial negotiation and closes the connection if the flags aren't what was expected (avoiding a down-negotiation attack).</p>
+<p id="rfc.section.4.p.3">In the old protocol, the server calculated and sent a MIC back to the client, which then verified that the command as received by the server was correct.  Not only does GSS-API already provide integrity protection, but this verification also happens after the server has already started running the command.  It has been dropped in the new protocol.</p>
+<p id="rfc.section.4.p.4">The old protocol doesn't require the client and server check the results of the GSS-API flag negotiation, although all old protocol clients passed GSS_C_MUTUAL_FLAG.  However, the old protocol requires gss_wrap be used for all payload with conf_req_flag set to non-zero, so any context that didn't negotiate confidentiality and integrity services would fail later.</p>
+<h1 id="rfc.references"><a href="#rfc.references">5.</a> References</h1>
+<h1 id="rfc.appendix.A"><a href="#rfc.appendix.A">Appendix A.</a> <a href="#credits" id="credits">Acknowledgements</a></h1>
+<p id="rfc.section.A.p.1">The original remctl protocol design was done by Anton Ushakov, with input from Russ Allbery and Roland Schemers.  Thank you to David Hoffman and Mike Newton for their review of the version 2 remctl protocol.</p>
+<h1 id="rfc.appendix.B"><a href="#rfc.appendix.B">Appendix B.</a> <a href="#license" id="license">Additional License</a></h1>
+<p id="rfc.section.B.p.1">This section supplements the Copyright Notice section at the start of this document.  It states an additional copyright notice and grants a much less restrictive license than the default IETF Trust license.  You may copy and distribute this document, with or without modification, under your choice of the license specified in the Copyright Notice section or the license below.</p>
+<p id="rfc.section.B.p.2">Copyright 2006, 2007, 2008, 2009, 2011, 2013 The Board of Trustees of the Leland Stanford Junior University</p>
+<p id="rfc.section.B.p.3">Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved.  This file is offered as-is, without any warranty.</p>
+<h1 id="rfc.authors">
+  <a href="#rfc.authors">Author's Address</a>
+</h1>
+<div class="avoidbreak">
+  <address class="vcard">
+	<span class="vcardline">
+	  <span class="fn">Russ Allbery</span> 
+	  <span class="n hidden">
+		<span class="family-name">Allbery</span>
+	  </span>
+	</span>
+	<span class="org vcardline">Stanford University</span>
+	<span class="adr">
+	  <span>255 Panama Street, MC 4136</span>
+
+	  <span class="vcardline">
+		<span class="locality">Stanford</span>,  
+		<span class="region">CA</span> 
+		<span class="code">94305-4136</span>
+	  </span>
+	  <span class="country-name vcardline">US</span>
+	</span>
+	<span class="vcardline">EMail: <a href="mailto:eagle@eyrie.org">eagle@eyrie.org</a></span>
+
+<span class="vcardline">URI: <a href="http://www.eyrie.org/~eagle/">http://www.eyrie.org/~eagle/</a></span>
 
-<p>MESSAGE_QUIT is a way of terminating the connection cleanly if
-        the client asked for keep-alive and then decided not to use it.
-        There is no message body.  Upon receiving this message, the server
-        MUST immediately close the connection.
-</p>
-<a name="noop"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.2.8"></a><h3>2.8.&nbsp;
-MESSAGE_NOOP</h3>
+  </address>
+</div>
+  
+  <hr class="noprint" />
+  <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
+  <ul class="toc">
 
-<p>MESSAGE_NOOP provides a way for a client to keep the connection
-        open to a remctl server, including through firewall session
-        timeouts and similar network constraints that require periodic
-        activity, without sending new commands.  There is no body.  When
-        the client sends a MESSAGE_NOOP message, the server replies with a
-        MESSAGE_NOOP message.
-</p>
-<p>Note that MESSAGE_NOOP was introduced in protocol version 3 and
-        therefore should be marked accordingly.  Clients should be
-        prepared for older servers to reply with MESSAGE_VERSION instead
-        of MESSAGE_NOOP.
-</p>
-<a name="proto1"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.3"></a><h3>3.&nbsp;
-Network Protocol (version 1)</h3>
+  	<li>1.   <a href="#rfc.section.1">Basic Packet Format</a></li>
+<li>2.   <a href="#rfc.section.2">Network Protocol (version 3)</a></li>
+<li>2.1.   <a href="#rfc.section.2.1">Session Sequence</a></li>
+<li>2.2.   <a href="#rfc.section.2.2">Message Format</a></li>
+<li>2.3.   <a href="#rfc.section.2.3">Protocol Version Negotiation</a></li>
+<li>2.4.   <a href="#rfc.section.2.4">MESSAGE_COMMAND</a></li>
+<li>2.5.   <a href="#rfc.section.2.5">MESSAGE_OUTPUT and MESSAGE_STATUS</a></li>
+<li>2.6.   <a href="#rfc.section.2.6">MESSAGE_ERROR</a></li>
+<li>2.7.   <a href="#rfc.section.2.7">MESSAGE_QUIT</a></li>
+<li>2.8.   <a href="#rfc.section.2.8">MESSAGE_NOOP</a></li>
+<li>3.   <a href="#rfc.section.3">Network Protocol (version 1)</a></li>
+<li>4.   <a href="#rfc.section.4">Security Considerations</a></li>
+<li>5.   <a href="#rfc.references">References</a></li>
+<li>Appendix A.   <a href="#rfc.appendix.A">Acknowledgements</a></li>
+<li>Appendix B.   <a href="#rfc.appendix.B">Additional License</a></li>
+<li><a href="#rfc.authors">Author's Address</a></li>
 
-<p>The old network protocol supported only 64KB of data payload,
-      only a single command and response, and had some additional
-      unnecessary protocol components.  It SHOULD NOT be used by clients,
-      but MAY be supported by servers for backward compatibility.  It is
-      recognized by the server and client by the lack of TOKEN_PROTOCOL in
-      the flags of the initial security context negotiation.
-</p>
-<p>The old protocol always uses the following steps:
-        </p>
-<ol class="text">
-<li>Client opens TCP connection to server.
-</li>
-<li>Client sends message with flags TOKEN_NOOP and
-          TOKEN_CONTEXT_NEXT and an empty payload.
-</li>
-<li>Client calls gss_init_sec_context and sends message with the
-          results and flags TOKEN_CONTEXT.  The client MUST pass
-          GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG as
-          requested flags and SHOULD pass GSS_C_REPLAY_FLAG and
-          GSS_C_SEQUENCE_FLAG, although the version one protocol does not
-          check the results of this negotiation.
-</li>
-<li>Server replies with the results of gss_accept_sec_context and
-          flags TOKEN_CONTEXT.
-</li>
-<li>Client calls gss_init_sec_context again with the data from
-          the server and replies with the results and flags TOKEN_CONTEXT,
-          using the same requested flags as described above.
-</li>
-<li>Server and client repeat, passing in the payload from the
-          last packet from the other side, for as long as GSS-API
-          indicates that continuation is required.  Each of these packets
-          have only TOKEN_CONTEXT set in the flags.
-</li>
-<li>Client sends command with flags TOKEN_DATA and TOKEN_SEND_MIC
-          and the following payload format:  four-octet number of
-          arguments, and then for each argument, a four-octet length and
-          then the argument value.  All numbers are in network type order.
-          The payload MUST be protected with gss_wrap and the
-          conf_req_flag parameter of gss_wrap MUST be set to non-zero,
-          requesting both confidentiality and integrity services.
-</li>
-<li>Server accepts and decrypts data, generates a MIC with
-          gss_get_mic, and sends the MIC back to the client with flags
-          TOKEN_MIC.  This is the only packet that isn't encrypted with
-          gss_wrap.  Client receives and then SHOULD verify this MIC.
-</li>
-<li>Server runs the command, collects the output, and sends the
-          output back with flags TOKEN_DATA and the following payload
-          format:  four-octet exit status, four-octet data length, data.
-          All numbers are in network byte order.  The exit status is 0 if
-          there were no errors and non-zero otherwise, where the meaning
-          of non-zero values are defined by the application.  The payload
-          MUST be protected with gss_wrap with a conf_req_flag set to
-          non-zero.
-</li>
-<li>Server and client close connection.
-</li>
-</ol><p>
-      
-</p>
-<a name="security"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.4"></a><h3>4.&nbsp;
-Security Considerations</h3>
 
-<p>It would be preferrable to insist on replay and sequence
-      protection (GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG) for all
-      contexts, but some older Kerberos GSS-API implementations don't
-      support this and hence it is not mandatory in the protocol.  Clients
-      SHOULD always request replay and sequence protection, however, and
-      servers MAY require such protection be negotiated.
-</p>
-<p>The old protocol doesn't provide integrity protection for the
-      flags, but since it always follows the same fixed sequence of
-      operations, this should pose no security concerns in practice.  The
-      new protocol only uses the flag field outside of the encrypted
-      section of the packet for initial negotiation and closes the
-      connection if the flags aren't what was expected (avoiding a
-      down-negotiation attack).
-</p>
-<p>In the old protocol, the server calculated and sent a MIC back to
-      the client, which then verified that the command as received by the
-      server was correct.  Not only does GSS-API already provide integrity
-      protection, but this verification also happens after the server has
-      already started running the command.  It has been dropped in the new
-      protocol.
-</p>
-<p>The old protocol doesn't require the client and server check the
-      results of the GSS-API flag negotiation, although all old protocol
-      clients passed GSS_C_MUTUAL_FLAG.  However, the old protocol
-      requires gss_wrap be used for all payload with conf_req_flag set to
-      non-zero, so any context that didn't negotiate confidentiality and
-      integrity services would fail later.
-</p>
-<a name="credits"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.A"></a><h3>Appendix A.&nbsp;
-Acknowledgements</h3>
+  </ul>
 
-<p>The original remctl protocol design was done by Anton Ushakov,
-      with input from Russ Allbery and Roland Schemers.  Thank you to
-      David Hoffman and Mike Newton for their review of the version 2
-      remctl protocol.
-</p>
-<a name="license"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<a name="rfc.section.B"></a><h3>Appendix B.&nbsp;
-License</h3>
+  
 
-<p>Copyright 2006, 2007, 2008, 2009, 2011, 2013 The Board of
-      Trustees of the Leland Stanford Junior University
-</p>
-<p>Copying and distribution of this file, with or without
-      modification, are permitted in any medium without royalty provided
-      the copyright notice and this notice are preserved.  This file is
-      offered as-is, without any warranty.
-</p>
-<a name="rfc.authors"></a><br /><hr />
-<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
-<h3>Author's Address</h3>
-<table width="99%" border="0" cellpadding="0" cellspacing="0">
-<tr><td class="author-text">&nbsp;</td>
-<td class="author-text">Russ Allbery</td></tr>
-<tr><td class="author-text">&nbsp;</td>
-<td class="author-text">Stanford University</td></tr>
-<tr><td class="author-text">&nbsp;</td>
-<td class="author-text">255 Panama Street, MC 4136</td></tr>
-<tr><td class="author-text">&nbsp;</td>
-<td class="author-text">Stanford, CA  94305-4136</td></tr>
-<tr><td class="author-text">&nbsp;</td>
-<td class="author-text">US</td></tr>
-<tr><td class="author" align="right">Email:&nbsp;</td>
-<td class="author-text"><a href="mailto:rra@stanford.edu">rra@stanford.edu</a></td></tr>
-<tr><td class="author" align="right">URI:&nbsp;</td>
-<td class="author-text"><a href="http://www.eyrie.org/~eagle/">http://www.eyrie.org/~eagle/</a></td></tr>
-</table>
-</body></html>
+</body>
+</html>
diff --git a/docs/protocol.txt b/docs/protocol.txt
index 17fbf0e..d3f6a86 100644
--- a/docs/protocol.txt
+++ b/docs/protocol.txt
@@ -1,12 +1,15 @@
 
 
 
-remctl Protocol                                               R. Allbery
-                                                     Stanford University
-                                                            October 2011
+
+Network Working Group                                         R. Allbery
+Internet-Draft                                       Stanford University
+Intended status: Informational                             December 2013
+Expires: June 4, 2014
 
 
               remctl: Remote Authenticated Command Service
+                        draft-allbery-remctl-00
 
 Abstract
 
@@ -18,100 +21,45 @@ Abstract
    described.  The version 1 protocol should only be implemented for
    backward compatibility.
 
+Status of This Memo
 
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
 
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
 
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
 
+   This Internet-Draft will expire on June 4, 2014.
 
+Copyright Notice
 
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
 
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allbery                                                         [Page 1]
+Allbery                   Expires June 4, 2014                  [Page 1]
 
-                                 remctl                     October 2011
-
-
-Table of Contents
-
-   1.  Basic Packet Format  . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Network Protocol (version 3) . . . . . . . . . . . . . . . . .  4
-     2.1.  Session Sequence . . . . . . . . . . . . . . . . . . . . .  4
-     2.2.  Message Format . . . . . . . . . . . . . . . . . . . . . .  5
-     2.3.  Protocol Version Negotiation . . . . . . . . . . . . . . .  5
-     2.4.  MESSAGE_COMMAND  . . . . . . . . . . . . . . . . . . . . .  6
-     2.5.  MESSAGE_OUTPUT and MESSAGE_STATUS  . . . . . . . . . . . .  7
-     2.6.  MESSAGE_ERROR  . . . . . . . . . . . . . . . . . . . . . .  8
-     2.7.  MESSAGE_QUIT . . . . . . . . . . . . . . . . . . . . . . .  9
-     2.8.  MESSAGE_NOOP . . . . . . . . . . . . . . . . . . . . . . .  9
-   3.  Network Protocol (version 1) . . . . . . . . . . . . . . . . . 10
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 13
-   Appendix B.  License . . . . . . . . . . . . . . . . . . . . . . . 14
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
+Internet-Draft                   remctl                    December 2013
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allbery                                                         [Page 2]
-
-                                 remctl                     October 2011
-
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
 
 1.  Basic Packet Format
 
@@ -121,9 +69,9 @@ Allbery                                                         [Page 2]
    registered port and the RECOMMENDED default for the protocol is 4373.
    Each data packet has the following format:
 
-       1 octet     flags
-       4 octets    length
-       <length>    data payload
+    1 octet     flags
+    4 octets    length
+    <length>    data payload
 
    The total size of each token, including the five octet prefix, MUST
    NOT be larger than 1,048,576 octets (1MB).
@@ -131,13 +79,13 @@ Allbery                                                         [Page 2]
    The flag octet contains one or more of the following values, combined
    with binary xor:
 
-       0x01        TOKEN_NOOP
-       0x02        TOKEN_CONTEXT
-       0x04        TOKEN_DATA
-       0x08        TOKEN_MIC
-       0x10        TOKEN_CONTEXT_NEXT
-       0x20        TOKEN_SEND_MIC
-       0x40        TOKEN_PROTOCOL
+    0x01        TOKEN_NOOP
+    0x02        TOKEN_CONTEXT
+    0x04        TOKEN_DATA
+    0x08        TOKEN_MIC
+    0x10        TOKEN_CONTEXT_NEXT
+    0x20        TOKEN_SEND_MIC
+    0x40        TOKEN_PROTOCOL
 
    Only TOKEN_CONTEXT, TOKEN_CONTEXT_NEXT, TOKEN_DATA, and
    TOKEN_PROTOCOL are used for packets for version 2 and of the
@@ -161,12 +109,9 @@ Allbery                                                         [Page 2]
 
 
 
-
-
-
-Allbery                                                         [Page 3]
+Allbery                   Expires June 4, 2014                  [Page 2]
 
-                                 remctl                     October 2011
+Internet-Draft                   remctl                    December 2013
 
 
 2.  Network Protocol (version 3)
@@ -212,19 +157,24 @@ Allbery                                                         [Page 3]
        GSS_C_INTEG_FLAG are set in the resulting security context and
        MUST immediately close the connection if this is not the case.
 
-   6.  After the security context has been established, the client and
-       server exchange commands and responses as described below.  All
-       commands are sent with flags TOKEN_DATA and TOKEN_PROTOCOL (0x44)
-       and the data payload of all packets is protected with gss_wrap.
-       The conf_req_flag parameter of gss_wrap MUST be set to non-zero,
 
 
 
-Allbery                                                         [Page 4]
+
+
+
+
+
+Allbery                   Expires June 4, 2014                  [Page 3]
 
-                                 remctl                     October 2011
+Internet-Draft                   remctl                    December 2013
 
 
+   6.  After the security context has been established, the client and
+       server exchange commands and responses as described below.  All
+       commands are sent with flags TOKEN_DATA and TOKEN_PROTOCOL (0x44)
+       and the data payload of all packets is protected with gss_wrap.
+       The conf_req_flag parameter of gss_wrap MUST be set to non-zero,
        requesting both confidentiality and integrity services.
 
 2.2.  Message Format
@@ -233,9 +183,9 @@ Allbery                                                         [Page 4]
    the data payload.  This is the format of the message before passing
    it to gss_wrap for confidentiality and integrity protection.
 
-       1 octet     protocol version
-       1 octet     message type
-       <command-specific data>
+    1 octet     protocol version
+    1 octet     message type
+    <command-specific data>
 
    The protocol version sent for all messages should be 2 with the
    exception of MESSAGE_NOOP, which should have a protocol version of 3.
@@ -245,13 +195,13 @@ Allbery                                                         [Page 4]
 
    The message type is one of the following constants:
 
-       1   MESSAGE_COMMAND
-       2   MESSAGE_QUIT
-       3   MESSAGE_OUTPUT
-       4   MESSAGE_STATUS
-       5   MESSAGE_ERROR
-       6   MESSAGE_VERSION
-       7   MESSAGE_NOOP
+    1   MESSAGE_COMMAND
+    2   MESSAGE_QUIT
+    3   MESSAGE_OUTPUT
+    4   MESSAGE_STATUS
+    5   MESSAGE_ERROR
+    6   MESSAGE_VERSION
+    7   MESSAGE_NOOP
 
    The first two message types are client messages and MUST NOT be sent
    by the server.  The remaining message types are server messages and
@@ -267,19 +217,18 @@ Allbery                                                         [Page 4]
    otherwise ignore the contents of the message and SHOULD respond with
    a message type of MESSAGE_VERSION and the following message payload:
 
-       1 octet     highest supported version
-
-   The client MUST then either send only messages supported at that
-   protocol version or lower or send MESSAGE_QUIT and close the
-   connection.
-
+    1 octet     highest supported version
 
 
 
-Allbery                                                         [Page 5]
+Allbery                   Expires June 4, 2014                  [Page 4]
 
-                                 remctl                     October 2011
+Internet-Draft                   remctl                    December 2013
+
 
+   The client MUST then either send only messages supported at that
+   protocol version or lower or send MESSAGE_QUIT and close the
+   connection.
 
    Currently, there are only two meaningful values for the highest
    supported version: 3, which indicates everything in this
@@ -291,12 +240,12 @@ Allbery                                                         [Page 5]
    Most client messages will be of type MESSAGE_COMMAND, which has the
    following format:
 
-       1 octet     keep-alive flag
-       1 octet     continue status
-       4 octets    number of arguments
-       4 octets    argument length
-       <length>    argument
-       ...
+    1 octet     keep-alive flag
+    1 octet     continue status
+    4 octets    number of arguments
+    4 octets    argument length
+    <length>    argument
+    ...
 
    If the keep-alive flag is 0, the server SHOULD close the connection
    after processing the command.  If it is 1, the server SHOULD leave
@@ -324,19 +273,20 @@ Allbery                                                         [Page 5]
    MESSAGE_COMMAND (with continue status 1) and the last octet would
    then be in the next MESSAGE_COMMAND (with continue status 2 or 3).
 
-   For as long as the continue status is 1 or 2, the next message from
-   the client MUST be either another MESSAGE_COMMAND with a continue
-   status of 2 or 3 or a MESSAGE_QUIT.  In other words, other message
-   types MUST NOT be intermixed with continued commands, but
-   MESSAGE_QUIT may be sent by the client in the middle of a continued
 
 
 
-Allbery                                                         [Page 6]
+
+Allbery                   Expires June 4, 2014                  [Page 5]
 
-                                 remctl                     October 2011
+Internet-Draft                   remctl                    December 2013
 
 
+   For as long as the continue status is 1 or 2, the next message from
+   the client MUST be either another MESSAGE_COMMAND with a continue
+   status of 2 or 3 or a MESSAGE_QUIT.  In other words, other message
+   types MUST NOT be intermixed with continued commands, but
+   MESSAGE_QUIT may be sent by the client in the middle of a continued
    command to abort that command.  If the server receives MESSAGE_QUIT
    from the client before receiving a MESSAGE_COMMAND with a status of 3
    (indicating the end of the command), the command MUST be discarded
@@ -371,9 +321,9 @@ Allbery                                                         [Page 6]
    messages followed by either a MESSAGE_STATUS or a MESSAGE_ERROR
    response.  Each MESSAGE_OUTPUT message has the following format:
 
-       1 octet     output stream
-       4 octets    output length
-       <length>    output
+    1 octet     output stream
+    4 octets    output length
+    <length>    output
 
    The output stream is either 1 for standard output or 2 for standard
    error.  Output length is a four-octet number in network byte order
@@ -381,18 +331,17 @@ Allbery                                                         [Page 6]
 
    The MESSAGE_STATUS message has the following format:
 
-       1 octet     exit status
-
-   MESSAGE_STATUS indicates the command has finished and returns the
-   final exit stauts of the command.  Exit status is 0 for success and
-
 
 
-Allbery                                                         [Page 7]
+Allbery                   Expires June 4, 2014                  [Page 6]
 
-                                 remctl                     October 2011
+Internet-Draft                   remctl                    December 2013
 
 
+    1 octet     exit status
+
+   MESSAGE_STATUS indicates the command has finished and returns the
+   final exit stauts of the command.  Exit status is 0 for success and
    non-zero for failure, where the meaning of non-zero exit statuses is
    left to the application to define.  (This is identical to a Unix
    command exit status.)
@@ -408,23 +357,23 @@ Allbery                                                         [Page 7]
    response after a MESSAGE_COMMAND, or it may be sent after one or more
    MESSAGE_OUTPUT messages.  The format of MESSAGE_ERROR is as follows:
 
-       4 octets    error code
-       4 octets    message length
-       <length>    error message
+    4 octets    error code
+    4 octets    message length
+    <length>    error message
 
    The error code is a four-octet number in network byte order
    indicating the type of error.  The error code may be one of the
    following values:
 
-       1  ERROR_INTERNAL           Internal server failure
-       2  ERROR_BAD_TOKEN          Invalid format in token
-       3  ERROR_UNKNOWN_MESSAGE    Unknown message type
-       4  ERROR_BAD_COMMAND        Invalid command format in token
-       5  ERROR_UNKNOWN_COMMAND    Unknown command
-       6  ERROR_ACCESS             Access denied
-       7  ERROR_TOOMANY_ARGS       Argument count exceeds server limit
-       8  ERROR_TOOMUCH_DATA       Argument size exceeds server limit
-       9  ERROR_UNEXPECTED_MESSAGE Message type not valid now
+    1  ERROR_INTERNAL           Internal server failure
+    2  ERROR_BAD_TOKEN          Invalid format in token
+    3  ERROR_UNKNOWN_MESSAGE    Unknown message type
+    4  ERROR_BAD_COMMAND        Invalid command format in token
+    5  ERROR_UNKNOWN_COMMAND    Unknown command
+    6  ERROR_ACCESS             Access denied
+    7  ERROR_TOOMANY_ARGS       Argument count exceeds server limit
+    8  ERROR_TOOMUCH_DATA       Argument size exceeds server limit
+    9  ERROR_UNEXPECTED_MESSAGE Message type not valid now
 
    Additional error codes may be added without changing the version of
    the remctl protocol, so clients MUST accept error codes other than
@@ -436,19 +385,20 @@ Allbery                                                         [Page 7]
    consumption and MUST NOT be interpreted by an automated process.
    Software should instead use the error code.
 
-   Unless the MESSAGE_COMMAND message from the client had the keep-alive
-   flag set to 1, the server MUST close the network connection
-   immediately after sending the MESSAGE_ERROR response message.
-   Otherwise, the server SHOULD still honor that flag, although the
-   server MAY terminate the connection after an unreasonable number of
 
 
 
-Allbery                                                         [Page 8]
+
+Allbery                   Expires June 4, 2014                  [Page 7]
 
-                                 remctl                     October 2011
+Internet-Draft                   remctl                    December 2013
 
 
+   Unless the MESSAGE_COMMAND message from the client had the keep-alive
+   flag set to 1, the server MUST close the network connection
+   immediately after sending the MESSAGE_ERROR response message.
+   Otherwise, the server SHOULD still honor that flag, although the
+   server MAY terminate the connection after an unreasonable number of
    errors.
 
 2.7.  MESSAGE_QUIT
@@ -471,40 +421,6 @@ Allbery                                                         [Page 8]
    for older servers to reply with MESSAGE_VERSION instead of
    MESSAGE_NOOP.
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allbery                                                         [Page 9]
-
-                                 remctl                     October 2011
-
-
 3.  Network Protocol (version 1)
 
    The old network protocol supported only 64KB of data payload, only a
@@ -521,6 +437,19 @@ Allbery                                                         [Page 9]
    2.   Client sends message with flags TOKEN_NOOP and
         TOKEN_CONTEXT_NEXT and an empty payload.
 
+
+
+
+
+
+
+
+
+Allbery                   Expires June 4, 2014                  [Page 8]
+
+Internet-Draft                   remctl                    December 2013
+
+
    3.   Client calls gss_init_sec_context and sends message with the
         results and flags TOKEN_CONTEXT.  The client MUST pass
         GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG as
@@ -553,14 +482,6 @@ Allbery                                                         [Page 9]
         TOKEN_MIC.  This is the only packet that isn't encrypted with
         gss_wrap.  Client receives and then SHOULD verify this MIC.
 
-
-
-
-Allbery                                                        [Page 10]
-
-                                 remctl                     October 2011
-
-
    9.   Server runs the command, collects the output, and sends the
         output back with flags TOKEN_DATA and the following payload
         format: four-octet exit status, four-octet data length, data.
@@ -580,41 +501,9 @@ Allbery                                                        [Page 10]
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allbery                                                        [Page 11]
+Allbery                   Expires June 4, 2014                  [Page 9]
 
-                                 remctl                     October 2011
+Internet-Draft                   remctl                    December 2013
 
 
 4.  Security Considerations
@@ -647,31 +536,7 @@ Allbery                                                        [Page 11]
    so any context that didn't negotiate confidentiality and integrity
    services would fail later.
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allbery                                                        [Page 12]
-
-                                 remctl                     October 2011
-
+5.  References
 
 Appendix A.  Acknowledgements
 
@@ -680,56 +545,22 @@ Appendix A.  Acknowledgements
    Hoffman and Mike Newton for their review of the version 2 remctl
    protocol.
 
+Appendix B.  Additional License
 
+   This section supplements the Copyright Notice section at the start of
+   this document.  It states an additional copyright notice and grants a
+   much less restrictive license than the default IETF Trust license.
+   You may copy and distribute this document, with or without
+   modification, under your choice of the license specified in the
+   Copyright Notice section or the license below.
 
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allbery                                                        [Page 13]
+Allbery                   Expires June 4, 2014                 [Page 10]
 
-                                 remctl                     October 2011
-
+Internet-Draft                   remctl                    December 2013
 
-Appendix B.  License
 
    Copyright 2006, 2007, 2008, 2009, 2011, 2013 The Board of Trustees of
    the Leland Stanford Junior University
@@ -739,52 +570,6 @@ Appendix B.  License
    notice and this notice are preserved.  This file is offered as-is,
    without any warranty.
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allbery                                                        [Page 14]
-
-                                 remctl                     October 2011
-
-
 Author's Address
 
    Russ Allbery
@@ -793,7 +578,7 @@ Author's Address
    Stanford, CA  94305-4136
    US
 
-   Email: rra@stanford.edu
+   Email: eagle@eyrie.org
    URI:   http://www.eyrie.org/~eagle/
 
 
@@ -828,13 +613,4 @@ Author's Address
 
 
 
-
-
-
-
-
-
-
-
-Allbery                                                        [Page 15]
-
+Allbery                   Expires June 4, 2014                 [Page 11]
diff --git a/docs/protocol.xml b/docs/protocol.xml
index 6ce6b39..fb02338 100644
--- a/docs/protocol.xml
+++ b/docs/protocol.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
 <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
 <?rfc private="remctl Protocol" toc="yes" symrefs="yes"?>
-<rfc>
+<rfc category="info" docName="draft-allbery-remctl-00" ipr="trust200902">
   <front>
     <title abbrev="remctl">remctl: Remote Authenticated Command Service</title>
     <author initials='R.' surname='Allbery' fullname='Russ Allbery'>
@@ -12,11 +12,11 @@
           <city>Stanford</city> <region>CA</region>
           <code>94305-4136</code> <country>US</country>
         </postal>
-        <email>rra@stanford.edu</email>
+        <email>eagle@eyrie.org</email>
         <uri>http://www.eyrie.org/~eagle/</uri>
       </address>
     </author>
-    <date month='October' year='2011' />
+    <date month='December' year='2013' />
 
     <abstract>
       <t>This document specifies the remctl wire protocol, used to send
@@ -491,7 +491,14 @@
       remctl protocol.</t>
     </section>
 
-    <section anchor='license' title='License'>
+    <section anchor='license' title='Additional License'>
+      <t>This section supplements the Copyright Notice section at the
+      start of this document.  It states an additional copyright notice
+      and grants a much less restrictive license than the default IETF
+      Trust license.  You may copy and distribute this document, with or
+      without modification, under your choice of the license specified in
+      the Copyright Notice section or the license below.</t>
+
       <t>Copyright 2006, 2007, 2008, 2009, 2011, 2013 The Board of
       Trustees of the Leland Stanford Junior University</t>
 
diff --git a/docs/remctl.1 b/docs/remctl.1
index aece75e..75fb481 100644
--- a/docs/remctl.1
+++ b/docs/remctl.1
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.26)
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -38,6 +38,8 @@
 .    ds PI \(*p
 .    ds L" ``
 .    ds R" ''
+.    ds C`
+.    ds C'
 'br\}
 .\"
 .\" Escape single quotes in literal strings from groff's Unicode transform.
@@ -48,17 +50,24 @@
 .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
-.ie \nF \{\
-.    de IX
-.    tm Index:\\$1\t\\n%\t"\\$2"
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
 ..
-.    nr % 0
-.    rr F
-.\}
-.el \{\
-.    de IX
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
 .\}
+.rr rF
 .\"
 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
@@ -124,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL 1"
-.TH REMCTL 1 "2013-08-14" "3.6" "remctl"
+.TH REMCTL 1 "2014-01-06" "3.7" "remctl"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -228,7 +237,7 @@ The current version of this program is available from its web page at
 .SH "AUTHOR"
 .IX Header "AUTHOR"
 Anton Ushakov <antonu@stanford.edu> is the original author.  Updates and
-current maintenance are done by Russ Allbery <rra@stanford.edu>.
+current maintenance are done by Russ Allbery <eagle@eyrie.org>.
 .SH "COPYRIGHT AND LICENSE"
 .IX Header "COPYRIGHT AND LICENSE"
 Copyright 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 The
diff --git a/docs/remctl.pod b/docs/remctl.pod
index 1bf44de..0fe4de5 100644
--- a/docs/remctl.pod
+++ b/docs/remctl.pod
@@ -119,7 +119,7 @@ L<http://www.eyrie.org/~eagle/software/remctl/>.
 =head1 AUTHOR
 
 Anton Ushakov <antonu@stanford.edu> is the original author.  Updates and
-current maintenance are done by Russ Allbery <rra@stanford.edu>.
+current maintenance are done by Russ Allbery <eagle@eyrie.org>.
 
 =head1 COPYRIGHT AND LICENSE
 
diff --git a/docs/remctld.8.in b/docs/remctld.8.in
index e0cc558..2744d12 100644
--- a/docs/remctld.8.in
+++ b/docs/remctld.8.in
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.26)
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -38,6 +38,8 @@
 .    ds PI \(*p
 .    ds L" ``
 .    ds R" ''
+.    ds C`
+.    ds C'
 'br\}
 .\"
 .\" Escape single quotes in literal strings from groff's Unicode transform.
@@ -48,17 +50,24 @@
 .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
-.ie \nF \{\
-.    de IX
-.    tm Index:\\$1\t\\n%\t"\\$2"
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
 ..
-.    nr % 0
-.    rr F
-.\}
-.el \{\
-.    de IX
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
 .\}
+.rr rF
 .\"
 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
@@ -124,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTLD 8"
-.TH REMCTLD 8 "2013-08-14" "3.6" "remctl"
+.TH REMCTLD 8 "2014-01-06" "3.7" "remctl"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -133,7 +142,7 @@
 remctld \- Server for remctl, a remote command execution utility
 .SH "SYNOPSIS"
 .IX Header "SYNOPSIS"
-remctld [\fB\-dFhmSv\fR] [\fB\-b\fR \fIbind-address\fR [\fB\-b\fR \fIbind-address\fR ...]]
+remctld [\fB\-dFhmSvZ\fR] [\fB\-b\fR \fIbind-address\fR [\fB\-b\fR \fIbind-address\fR ...]]
     [\fB\-f\fR \fIconfig\fR] [\fB\-k\fR \fIkeytab\fR] [\fB\-P\fR \fIfile\fR] [\fB\-p\fR \fIport\fR]
     [\fB\-s\fR \fIservice\fR]
 .SH "DESCRIPTION"
@@ -153,8 +162,8 @@ daemon facility).
 .PP
 The location of the configuration file may be specified with the \fB\-f\fR
 option.  The default location is \fI\f(CI@sysconfdir\fI@/remctl.conf\fR.  For
-information on the format of the configuration file, see \*(L"\s-1CONFIGURATION\s0
-\&\s-1FILE\s0\*(R" below.
+information on the format of the configuration file, see \*(L"\s-1CONFIGURATION
+FILE\*(R"\s0 below.
 .PP
 When the command is run, several environment variables will be set
 providing information about the remote connection.  See \s-1ENVIRONMENT\s0
@@ -210,7 +219,7 @@ When running in stand-alone mode (\fB\-m\fR), write the \s-1PID\s0 of \fBremctld
 \&\fIfile\fR.  This option is ignored unless \fB\-m\fR is also given.
 .IP "\fB\-p\fR \fIport\fR" 4
 .IX Item "-p port"
-When running in stand-alone mode, Listen on port \fIport\fR rather than the
+When running in stand-alone mode, listen on port \fIport\fR rather than the
 default.  This option does nothing unless used with \fB\-m\fR.
 .IP "\fB\-S\fR" 4
 .IX Item "-S"
@@ -227,6 +236,14 @@ with the \fB\-k\fR option).  This is normally the most desirable behavior.
 .IP "\fB\-v\fR" 4
 .IX Item "-v"
 Print the version of \fBremctld\fR and exit.
+.IP "\fB\-Z\fR" 4
+.IX Item "-Z"
+When \fBremctld\fR is running in stand-alone mode, after it has set up its
+network socket and is ready to answer requests, raise \s-1SIGSTOP. \s0 This
+signals to upstart, when using \f(CW\*(C`expect stop\*(C'\fR, that the daemon is ready to
+accept connections, and upstart will raise \s-1SIGCONT\s0 to allow \fBremctld\fR to
+continue.  This option is probably only useful when using upstart as the
+init system.  Only makes sense in combination with \fB\-m\fR.
 .SH "CONFIGURATION FILE"
 .IX Header "CONFIGURATION FILE"
 The configuration file defines the allowed commands and specifies access
@@ -381,7 +398,7 @@ with a \fIsubcommand\fR of \f(CW\*(C`ALL\*(C'\fR.
 .IP "user=(\fIusername\fR | \fIuid\fR)" 4
 .IX Item "user=(username | uid)"
 Run this command as the specified user, which can be given as either a
-username or as a \s-1UID\s0.  Even if given as a \s-1UID\s0, the user must be found in
+username or as a \s-1UID. \s0 Even if given as a \s-1UID,\s0 the user must be found in
 the user database (searched via \fIgetpwuid\fR\|(3)).  \fBremctld\fR will run the
 command as the specified user, including that user's primary and
 supplemental groups.
@@ -457,7 +474,7 @@ alone does not grant access to anyone, and using deny on itself as in
 \&\f(CW\*(C`deny:deny:foo\*(C'\fR neither denies nor grants access to anyone.
 .IP "gput" 4
 .IX Item "gput"
-This method is used to grant access based on the \s-1CMU\s0 \s-1GPUT\s0 (Global
+This method is used to grant access based on the \s-1CMU GPUT \s0(Global
 Privileged User Table \*(-- see \fIgput\fR\|(5)).  The data is either a \s-1GPUT\s0 role
 name or a string of the form \fIgroup\fR[\fIxform\fR], where \fIgroup\fR is a \s-1GPUT\s0
 role name and \fIxform\fR is a \s-1GPUT\s0 transform string.  Access is granted if
@@ -496,6 +513,32 @@ without any \fImethod\fR: prefixes.
 .RE
 .SH "ENVIRONMENT"
 .IX Header "ENVIRONMENT"
+\&\fBremctld\fR itself uses the following environment variables when run in
+stand-alone mode (\fB\-m\fR):
+.IP "\s-1LISTEN_FDS\s0" 4
+.IX Item "LISTEN_FDS"
+.PD 0
+.IP "\s-1LISTEN_PID\s0" 4
+.IX Item "LISTEN_PID"
+.PD
+If these environment variables are set, \fBremctld\fR will expect to be
+provided its listening sockets via the systemd socket activation protocol
+and will not attempt to bind its own sockets.  For more details on the
+protocol, see \fIdaemon\fR\|(7) and \fIsd_listen_fds\fR\|(3).
+.IP "\s-1NOTIFY_SOCKET\s0" 4
+.IX Item "NOTIFY_SOCKET"
+If this environment variable is set, \fBremctld\fR will notify the socket
+named in this variable when it is ready to accept incoming packets using
+the systemd status notification protocol.  For more details, see
+\&\fIdaemon\fR\|(7) and \fIsd_notify\fR\|(3).
+.Sp
+Note that using socket activation is recommended when running under
+systemd in stand-alone mode, and status notification is not necessary or
+useful when using socket activation.
+.PP
+When running in stand-alone mode, these environment variables will be
+cleared by \fBremctld\fR before running any commands.
+.PP
 The following environment variables will be set for any commands run via
 \&\fBremctld\fR:
 .IP "\s-1REMOTE_USER\s0" 4
@@ -629,7 +672,7 @@ The current version of this program is available from its web page at
 .SH "AUTHOR"
 .IX Header "AUTHOR"
 Anton Ushakov <antonu@stanford.edu> is the original author.  Updates and
-current maintenance are done by Russ Allbery <rra@stanford.edu>.
+current maintenance are done by Russ Allbery <eagle@eyrie.org>.
 .SH "COPYRIGHT AND LICENSE"
 .IX Header "COPYRIGHT AND LICENSE"
 Copyright 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
diff --git a/docs/remctld.pod b/docs/remctld.pod
index 8cebce6..6ab0e37 100644
--- a/docs/remctld.pod
+++ b/docs/remctld.pod
@@ -1,8 +1,9 @@
 =for stopwords
-remctld remctl -dFhmSv keytab GSS-API tcpserver inetd subcommand AFS
+remctld remctl -dFhmSvZ keytab GSS-API tcpserver inetd subcommand AFS
 backend logmask NUL acl ACL princ filename gput CMU GPUT xform ANYUSER IP
 IPv4 IPv6 hostname SCPRINCIPAL sysctld Heimdal MICs Ushakov Allbery
 subcommands REMUSER pcre PCRE triple-DES MERCHANTABILITY username arg
+SIGCONT SIGSTOP systemd
 
 =head1 NAME
 
@@ -10,7 +11,7 @@ remctld - Server for remctl, a remote command execution utility
 
 =head1 SYNOPSIS
 
-remctld [B<-dFhmSv>] [B<-b> I<bind-address> [B<-b> I<bind-address> ...]]
+remctld [B<-dFhmSvZ>] [B<-b> I<bind-address> [B<-b> I<bind-address> ...]]
     [B<-f> I<config>] [B<-k> I<keytab>] [B<-P> I<file>] [B<-p> I<port>]
     [B<-s> I<service>]
 
@@ -99,7 +100,7 @@ I<file>.  This option is ignored unless B<-m> is also given.
 
 =item B<-p> I<port>
 
-When running in stand-alone mode, Listen on port I<port> rather than the
+When running in stand-alone mode, listen on port I<port> rather than the
 default.  This option does nothing unless used with B<-m>.
 
 =item B<-S>
@@ -120,6 +121,15 @@ with the B<-k> option).  This is normally the most desirable behavior.
 
 Print the version of B<remctld> and exit.
 
+=item B<-Z>
+
+When B<remctld> is running in stand-alone mode, after it has set up its
+network socket and is ready to answer requests, raise SIGSTOP.  This
+signals to upstart, when using C<expect stop>, that the daemon is ready to
+accept connections, and upstart will raise SIGCONT to allow B<remctld> to
+continue.  This option is probably only useful when using upstart as the
+init system.  Only makes sense in combination with B<-m>.
+
 =back
 
 =head1 CONFIGURATION FILE
@@ -400,6 +410,36 @@ without any I<method>: prefixes.
 
 =head1 ENVIRONMENT
 
+B<remctld> itself uses the following environment variables when run in
+stand-alone mode (B<-m>):
+
+=over 4
+
+=item LISTEN_FDS
+
+=item LISTEN_PID
+
+If these environment variables are set, B<remctld> will expect to be
+provided its listening sockets via the systemd socket activation protocol
+and will not attempt to bind its own sockets.  For more details on the
+protocol, see L<daemon(7)> and L<sd_listen_fds(3)>.
+
+=item NOTIFY_SOCKET
+
+If this environment variable is set, B<remctld> will notify the socket
+named in this variable when it is ready to accept incoming packets using
+the systemd status notification protocol.  For more details, see
+L<daemon(7)> and L<sd_notify(3)>.
+
+Note that using socket activation is recommended when running under
+systemd in stand-alone mode, and status notification is not necessary or
+useful when using socket activation.
+
+=back
+
+When running in stand-alone mode, these environment variables will be
+cleared by B<remctld> before running any commands.
+
 The following environment variables will be set for any commands run via
 B<remctld>:
 
@@ -532,7 +572,7 @@ L<http://www.eyrie.org/~eagle/software/remctl/>.
 =head1 AUTHOR
 
 Anton Ushakov <antonu@stanford.edu> is the original author.  Updates and
-current maintenance are done by Russ Allbery <rra@stanford.edu>.
+current maintenance are done by Russ Allbery <eagle@eyrie.org>.
 
 =head1 COPYRIGHT AND LICENSE