On Thu, Oct 3, 2019 at 10:19 AM Christopher Wood <c...@heapingbits.net> wrote:
> On Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote: > > On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood <c...@heapingbits.net> > wrote: > > > > > > > I understand the meaning of count is the higher limit of ticket and > the > > > > server can provides any tickets between 0 and count. If that is > > > > correct, this could be clearly stated and indication to chose an > > > > appropriated value for each cases may be provided. > > > > > > The document states this: > > > > > > A supporting server MAY vend TicketRequestContents.count > > > NewSessionTicket messages to a requesting client, and SHOULD NOT send > > > more than TicketRequestContents.count NewSessionTicket messages to a > > > requesting client. > > > > > > Is this not sufficient clear? If not, how can it be improved? > > > > RFC2119 "SHOULD/SHOULD NOT" requirements are usually clearer with some > > examples of "valid reasons in particular circumstances to ignore a > > particular item" [RFC2119]. Otherwise, those requirements can be > > cryptic, and perhaps better-described by MAY or MUST language. > > I understand, though I'm not sure more text is needed here. If you > disagree, can you please suggest text to make it more clear? > The current text the describes the interaction well enough, but I don't understand the requirement. I can suggest two alternatives: 1) A supporting server [...] MAY send more than TicketRequestContents.count NewSessionTicket messages to a requesting client. The client might not be able to use all of them. 2) A supporting server [...] MUST NOT send more than TicketRequestContents.count NewSessionTicket messages to a requesting client. The draft uses "SHOULD NOT". Why is that? Perhaps that trailing sentence I added to 1) seems obvious to the authors? I did not automatically assume the consequences of sending extra NewSessionTicket messages would be so innocuous. If that's the case, it seems like MAY would be better, since clients need to handle extra NewSessionTicket messages, even if they just discard them. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
