Re: [core] I-D Action: draft-ietf-core-stateless-02.txt

[Klaus Hartke <[e-mail]>]

Thomas Fossati wrote:
> > The intention was to say: If the value is less than 8, then it shall
> > be set to 8. If it's greater than 65804, then it shall be set to
> > 65804. I though that's what clamping means, no?
>
> Sure, it's not "clamp" but the following "to be *within* this range"
> that creates the ambiguity.

So maybe just this?

            The option value MUST NOT be less than 8 or greater than 65804. When
            an option value outside this range is received, the value MUST be
            clamped to this range.

(I'm not a native speaker; help is appreciated.)

> Thanks.  This is exactly what I meant by "dense": it looks like there is
> an interesting amount of relevant information that is left implicit.  I
> think articulating the assumptions as you just did will make it easier
> on future readers.
>
> [...]
>
> The latter looks like a 4.xx to me.

Like so?

   If a server supports extended token lengths but receives a request
   with a token of a length it is unwilling or unable to handle, it MUST
   NOT reject the message, as that would imply that extended token
   lengths are not supported at all.  Instead, if the condition is
   temporary, it SHOULD return a 5.03 (Service Unavailable) response.
   If the condition is permanent, it SHOULD return a 4.00 (Bad Request)
   response.

   Design Note:  The requirement to return an error response when a
      request cannot be handled might seem somewhat contradictory.
      However, handling a request usually involves a number of steps
      from receiving the message to handing it over to application
      logic.  The idea is that a server implementing this document at
      least should support large tokens in the first few steps (enough
      to return an error response rather than a Reset message).

Klaus