Re: [PATCH v2 01/11] docs: new capability to advertise trace2 SIDs

[Josh Steadmon <steadmon@google.com>]

On 2020.11.03 13:33, Junio C Hamano wrote:
> Josh Steadmon <steadmon@google.com> writes:
> 
> > +trace2-sid=<session-id>
> > +-----------------------
> > +
> > +If trace2 tracing is enabled on the server, it may advertise its session ID via
> > +this capability. The client may choose to log the server's session ID in its
> > +trace logs, and advertise its own session ID back to the server for it to log
> > +as well. This allows for easier debugging of remote sessions when both client
> > +and server logs are available.
> > diff --git a/Documentation/technical/protocol-v2.txt b/Documentation/technical/protocol-v2.txt
> > index e597b74da3..a5b9ef04f6 100644
> > --- a/Documentation/technical/protocol-v2.txt
> > +++ b/Documentation/technical/protocol-v2.txt
> > @@ -492,3 +492,12 @@ form `object-format=X`) to notify the client that the server is able to deal
> >  with objects using hash algorithm X.  If not specified, the server is assumed to
> >  only handle SHA-1.  If the client would like to use a hash algorithm other than
> >  SHA-1, it should specify its object-format string.
> > +
> > +trace2-sid=<session-id>
> > +~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +If trace2 tracing is enabled on the server, it may advertise its session ID via
> > +this capability. The client may choose to log the server's session ID in its
> > +trace logs, and advertise its own session ID back to the server for it to log
> > +as well. This allows for easier debugging of remote sessions when both client
> > +and server logs are available.
> 
> Have we documented what a session-id should look like anywhere in
> the documentation?  This document is to help third-party to write
> implementations of the protocol, but the above description leaves
> things "implementation defined" a bit too much, I am afraid.
> 
> For example, as this must fit on a single pkt-line as an advertised
> capability, there would be some length limit.  Are there other
> inherent limitations due to our protocol?  Are there some artificial
> limitations that we may want to impose to make it easier to harden
> implementations against common mistakes?  For example are bytes in
> <session-id> allowed to contain LF, CR, NUL, etc.?

Documented in V3. For argument's sake, I'm going to say that the tokens
should be limited to printable, non-whitespace characters, and should
fit on a single pkt-line.