On Sat, May 12, 2012 at 12:39 PM, Richard Alimi <[email protected]> wrote: <snipped> >> If I understand JASONString correctly, no language tag is supplied, >> so human readability will be highly variable, Fixing that, rather >> than relying on a local mapping of the underlying code, is hard >> work. Dropping this optional aspect of the error resource may >> be something for the WG to consider; this pushes localization >> of the error code description to the endpoint. > > That seems reasonable. The intent was to help with debugging (and not > display to a user), so I'd either be okay with removing it or keeping > it and not worrying about the language. Is there standard guidance to > apply here? >
I don't think there is standard guidance. My personal advice, free today and worth what you pay for it, is that localization of error codes works better if the client simply has a local table of what maps to the code. If you have to do language negotiation just to get the error string right, you're introducing a lot of complexity for marginal gain. If it's a debug string, rather than a user-facing error, then marking it such and noting it will contain arcana rather than actual error explanations is probably okay. I don't think many people expect a localized stack trace. <much snipped> > Yes - I see the disconnect. I'd like to avoid solving the larger > deployment considerations under NATs (the deployment consideratoins > document should be handling that) in this document and instead focus > on the messaging details. I haven't read the deployment considerations doc, but if this is handled there, then a pointer to that would be fine. > Perhaps it would be best to change the > statement w.r.t. STUN to instead say MAY. This document can certainly > give a concise statement of the problems you identified there. > > How does that sound? > I don't think it is really a question of MAY vs. SHOULD. The document seems to be assigning responsibility to working out the NAT boundary problem to the client. That means the client needs some way of determining whether it is going through an address translator to reach the target. I think keeping it at SHOULD use STUN for cases where a translation will take place is correct; the problem is it is SHOULD NOT for cases where the source and destination are within a NAT boundary. If you can, I would personally say something brief like that, and give a pointer to the deployment considerations document for more on how you determine when you have each case. The optimization (omitting the Source Endpoint), just highlights the problem. regards, Ted Hardie _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
