On 04/22/2018 08:30 PM, Peter Saint-Andre wrote: > On 4/21/18 3:39 PM, Marc Petit-Huguenin wrote: > >>>>>> Section 6.3.4 states: >>>>>> >>>>>> o If the error code is 500 through 599, the client MAY resend the >>>>>> request; clients that do so MUST limit the number of times they do >>>>>> this. >>>>>> >>>>>> It is reasonable to provide guidance as to the number of re-sends? >>>>> >>>>> Same issue here, that's a section that is unmodified from RFC 5389. >>>> >>>> I understand. Now is our chance to fix it. :-) >>>> >>>>> As long as the client does not enter an endless loop of retransmission, choosing different numbers of re-sends does not affect interoperability. >>>> >>>> Choosing different numbers is OK, but choosing an infinite number is >>>> not. Can we provide guidance as to how many is too many? 10? 50? 100? >>> >>> Well, the text already states that an infinite number of of re-sends is not compliant. Anyway, I am not sure how to determine a reasonable number, but I'll try. >> >> I chose 4 as the maximum number of retransmissions. I based that on error code 508 in TURN that defines a delay of 60 seconds between retransmissions, so we now get a delay of 5 minutes before the client gives up in case of insufficient capacity. The new text reads like this: >> >> "o If the error code is 500 through 599, the client MAY resend the >> request; clients that do so MUST limit the number of times they do >> this. Unless a specific error code specifies a different value, >> the number of retransmissions MUST be limited to 4." >> > > "SHOULD be limited to 4" seems fine, but MUST is OK too. > Changed to SHOULD. Thanks. -- Marc Petit-Huguenin Email: marc@xxxxxxxxxxxxxxxxxx Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug
Attachment:
signature.asc
Description: OpenPGP digital signature
