> >> Providing additional information in abort packets seems reasonable, but >> let's think carefully about how to do it. >> >> Is the "reason code" you propose simply a sub-error-code, which means >> you have a table of possible reasons for every possible error code?
Time-tested solution (been working for decades in other protocols): 3 32-bit values: Error code (in this case ABORT) Reason code (32-bit reason) Suggested Action: (32-bit action table) Reasons could be (TOO_MANY_REQUESTS, EXPLICIT_CONGESTION_NOTIFICATION, etc) Suggested actions could be (THROTTLE_DOWN, CHOOSE_ANOTHER_SERVER, etc) 32 bits worth of actions per reason code ought to be plenty. > >> What about a human-readable message? >> And if we do that, what about internationalization? > >Maybe. Please, no. That's user-level stuff, not on the wire stuff. Translate the message when you log it, not in the packet. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
