For any message received from a client that includes this tag, the server MUST include the same tag and value in any response required from this message where it is feasible to do so.
In other words, the spec improves message grouping. Still, it doesn't make the whole thing robust: when writing an IRC client with labeled-response support, one must also handle cases when the server doesn't reply with a BATCH, an ACK or a message with the same label.
This is, IIUC, due to S2S connections being unreliable, and thus the leaf server cannot answer with a batch every time (correct me if I'm wrong).
On the other hand some IRCd (ellidri, also oragono I suppose) always reply with the label. However there is currently no way for a client to know whether this is true from any server.
To improve this, I suggest the labeled-response capability have an argument, called strict (TBD). When a server advertise this argument, it MUST reply with the label when the client sends (a correct) one.
Example of a Client connecting to a Server with strict support of labeled-response.
C->S: NICK nick
C->S: CAP LS 302
C->S: USER u s e r
S->C: :irc.example.com CAP nick LS :batch labeled-response=strict
C->S: CAP REQ :batch labeled-response
S->C: :irc.example.com CAP ACK :batch labeled-response
C->S: @label=welcome CAP END
S->C: @label=welcome :irc.example.com BATCH +0 labeled-response
S->C: @batch=0 :irc.example.com 001 nick :Welcome home, nick
...
S->C: @batch=0 :irc.example.com 376 nick :End of MOTD
S->C: :irc.example.com BATCH -0
...
On a side note, considering how few implementations have labeled-response support, I suppose this can be specified the other way: when a server advertises labeled-response, it MUST honor all labels coming from the client. Servers that cannot hold this property (because of S2S or whatever) would advertise labeled-response=lax. In my opinion (change my mind!), there is little value in labeled-response as it specified right now, having this "strict" property would make client implementations simpler.
From the labeled-response spec, emphasis mine:
In other words, the spec improves message grouping. Still, it doesn't make the whole thing robust: when writing an IRC client with labeled-response support, one must also handle cases when the server doesn't reply with a BATCH, an ACK or a message with the same label.
This is, IIUC, due to S2S connections being unreliable, and thus the leaf server cannot answer with a batch every time (correct me if I'm wrong).
On the other hand some IRCd (ellidri, also oragono I suppose) always reply with the label. However there is currently no way for a client to know whether this is true from any server.
To improve this, I suggest the labeled-response capability have an argument, called
strict(TBD). When a server advertise this argument, it MUST reply with the label when the client sends (a correct) one.Example of a Client connecting to a Server with strict support of labeled-response.
On a side note, considering how few implementations have labeled-response support, I suppose this can be specified the other way: when a server advertises labeled-response, it MUST honor all labels coming from the client. Servers that cannot hold this property (because of S2S or whatever) would advertise
labeled-response=lax. In my opinion (change my mind!), there is little value in labeled-response as it specified right now, having this "strict" property would make client implementations simpler.