Re: [core] [Last-Call] [art] Artart last call review of draft-ietf-core-problem-details-05

[Carsten Bormann <[e-mail]>]

Hi Martin,

thank you for your further explanations.

>>> What we don't yet agree is how this is presented. You want to present it as three values and one separate case/choice of an absent value.
>> Yes, because choosing a value is very different from supplying one or not supplying one.
> 
> I still think that from an implementer's point, and from a user point, and from an information-theoretic point, it's four choices. That three of these choices take up one byte each, whereas the fourth choice takes up 0 bytes, is in my view a detail. But anyhow, I think the new text in -07 makes it much more difficult to be confused about whether there are three or four choices; the -06 made that very difficult because absence was mentioned before a null value, and both were together in the same sentence, separated only by a semicolon.

As I think you are saying, the updated text in -07 is an editorial improvement and should resolve the concern.

[…]

>>>> Base-rtl and base-lang are specified to apply to unadorned (non-tag-38) strings.
>>>> It is not defined in the current text whether an implementation would apply base-rtl to tag-38 strings with absent directionality.
>>> 
>>> I think it's bad practice to leave things like this open. The only result it can produce is confusion, and nobody benefits from that. Why not just say that base-rtl and base-lang apply if language or direction are missing on a tag-38?
>> Because tag 38 operates independent from the enclosing problem-details document.
>> It needs to be possible to implement tag 38 in its own library.
>> If that happens to have a way to supply default parameters, these could be taken from base-rtl/-lang in the calling problem-details implementation.
> 
> There's really no point in going halfway in specifying bidi for problem details. What you want is that senders (e.g. servers sending a problem detail; ultimately programmers/translators that prepared the text(s) in that problem detail) have the confidence that the text(s) they prepared get displayed the way they intended so the reader on the client side will understand them without having to guess what was messed up.

If the generator knows what it wants, it can set ltr/rtl, that is easy.
The hard part is what it can do when it doesn’t.

Not specifying directionality (absent third element) is one way; the data item generator by this essentially leaves everything to the data item consumer.  Note that this allows that the consumer can be wiser than the generator; having the generator dictate what the consumer must do in this case is counterproductive.  

For the consumer, we do suggest defaulting absent to “auto” if no other context is available.

Explicit null (“auto”), again, means that the generator does not know enough to set ltr/rtl; but it does know that any additional context in the data item won’t help (e.g., because the controlled text is imported from a different environment than the text in the rest of the data item).
Here again, asking the generator to specify something it doesn’t know does not make sense.

The FSI..PDI suggestion is just a suggestion, “auto” does not “mean” FSI.
(If the generator knows the directionality of the text, it’ll set rtl or ltr and not auto.)  You may argue this “leaves things open”, I would argue that this is the case where there isn’t enough information on the generator side to nail anything down.

> An implementation of tag 38 "in its own library" will most probably come with a way to supply a default parameter; otherwise, the implementers haven't really read the spec.

Yes.

> Of course there will be implementations on constrained devices that completely ignore directionality because they are not intended for the Middle-Eastern market. They will not contain fonts for Arabic or Hebrew either, and that's just fine, but a separate consideration.

Indeed, that is the problem — but one interesting case is where the constrained device doesn’t know much, the less-constrained correspondent does.  The objective here is to make these asymmetric situations work.

>> […]
>>>>> 
>>>>> We should make sure that the text of the RFC to be encourages 3), not 1) or 2).
>>>> To me, (3) is really “follow the flow”, which is just a short way of saying “the reader is advised to consult ongoing standardization activities”.
>>> 
>>> There are no ongoing standardization activities on the bidi algorithm. If you say that a string of text is in RTL (or LTR) isolation, or in first strong isolation, what that means is defined by Unicode Standard Annex #9, which doesn't "flow" at all.
>> Indeed, that’s why we now reference Annex #9 in all three places.
>> However, the reference to FSI is weaker, as this is just one “auto” algorithm, and the document leaves handling “auto” more open than “ltr” and “rtl” (which are now quite sharp based on your help).
> 
> I still don't understand this. What's the point of a standard if stuff is left open? What we want is that somebody who creates/translates the text of a problem detail is able to precisely express what their understanding/expectations with regards to directionality is. Just saying "something automatic may happen, and it may be equivalent to first strong isolation, or it may be something else" doesn't guarantee that, the only thing it guarantees is a mess.
> 
> I agree that there are other "auto" algorithms, but they are really, really not popular. The only "auto" algorithm that TR #9 uses is first strong (as already explained in detail in an earlier mail, see below). It's also the easiest to implement, in particular on constrained devices.

You are comparing general algorithms.  But one of the two peers might know more and be able to apply that knowledge.  The current text for “auto” is designed to allow this.

>> […]
>>> But what's much more important here is that the solution is NOT to go read STRING-META, because STRING-META won't help. STRING-META shows different ways of how one could indicate directionality in different cases. You already made your choice, so STRING-META is no longer relevant. What counts is the Unicode Bidirectional Algorithm.
>>> 
>>>> We left in a weaker reference (Readers interested in further details […] may want to consult […]) to STRING-META as that is still useful background material for further reading.
>>> 
>>> This is still misleading, because readers of your document don't have much of a reason to read that document. The main reason may be to answer questions such as "why do we need such a directionality indicator", but if that's the case, your text should be more specific.
>> OK, I took out the “for further reading” paragraph.
> 
> Very good, thanks.
> 
>> As an implementer, I’d probably have benefitted from some background material that explains enough so it can take me off the knee-jerk “what the heck is this” reaction.
>> But for people who already know a bit about this space, too much information may indeed be confusing.
> 
> If you want some background for implementers, which I think is a reasonable concern, then there are other documents better suited than STRING-META (which is mainly for spec writers).
> 
> A quick search on https://www.w3.org/International/ brought up e.g. the following:
> https://www.w3.org/International/articles/strings-and-bidi/
> https://www.w3.org/International/articles/lang-bidi-use-cases/
> https://www.w3.org/International/articles/inline-bidi-markup/uba-basics
> But there might be even better resources.

Thank you for the pointers.  I’m planning to make a PR to draft-bormann-cbor-notable-tags.
The notable-tags draft is intended to explain more about usage and implementation of certain tags, including when to choose which.  
It is probably a better place to include pointers to knowledge that is still growing, so I would expect us to direct further work there.

Grüße, Carsten