Re: [apps-discuss] Review of draft-ietf-alto-protocol-11.txt

[Ted Hardie <[e-mail]>]

On Sat, May 12, 2012 at 12:39 PM, Richard Alimi <[e-mail]> 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