Hi John,
> If you, as document author, don't know or cannot specify where
> the determining context comes from, isn't omitting the keyword
> and value equivalent to "do whatever you feel like, possibly
> considering whatever else you can figure out"? If that is
> actually the case, why not just say that?
I thought we did say that, but not in a sense of “arbitrarily do whatever you like”, but in a sense of acting responsibly on the information you have.
> Or, as one
> alternative, why not make it explicit that the keyword and value
> (probably even in the "null"/auto case are optional only if the
> language and script are strictly LTR?
I don’t think this is explicit or implicit here.
> Backing up a bit, you (and presumably the WG) concluded, even
> before you sought external advice, that specifying direction is
> important. Then you added these two options ("null" and omitted
> entirely) to allow not specifying it. That feels to me like we
> are going around in circles or, at least, shifting
> responsibility for making the decisions to people who may be
> much less expert on the subject than the WG (much less the WG
> with help from IETF Last Call).
The objective of this protocol is to provide problem detail data that a requesting client can act upon, preferably by sending a modified request that better solves their problem. Human-readable information can be an (important) byproduct, but it is not the focus for this work.
The fact that we actually had to provide an update to tag 38 is an indication of how far the desirables are from what we actually find today.
> So, suggestions (pick one):
>
> (1) Get rid of the two "make up your own mind" options and
> require the value
>
> (2) Spell out the circumstances under which the value MUST be
> specified, indicate that it MAY be present in any of the other
> cases, and then move on.
Let’s not get carried away here.
The objective is to make it easy for implementers to provide this information if they want to provide it (having it in the first place is probably a prerequisite to that).
Trying to force them to provide information they cannot easily avail themselves of means that the protocol will not be deployed.
> (3) If you can describe coherently what it would mean in a way
> that would cover all cases, make the third value "inherited" and
> make omitting the parameter exactly equivalent to it.
> "Inherited" is the only way in which "from context" appears to
> me to make sense. If I am missing other cases that would
> dictate context, that makes spelling out when the third and
> forth options are useful even more important.
There are two cases here: defined by context (signified by absence) and “auto” (signified by `null`). I think these are pretty well-defined now.
> Free advice: Don't do (3) unless you think it is absolutely
> necessary: the odds of getting further bogged down are very high.
I’m not sure I understand who would be bogged down by what.
The point, as I said, is not to make the protocol undeployable.
Grüße, Carsten
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
