Hi,
If that is correct, my impression is that defining such a higher level protocol is a bit out of scope of these documents and opens the door to something way more complex - Maybe I am wrong. A middle ground area could be to provide some recommendations that we are aware of, without claiming we have achieved something complete. I also tend to think that such work could be handled in the future and would have a limited effect on the current specs. The current ones are more on the model structure, that spec would be more specific on how elements are displayed.
My concerns are whether a complete unambiguous specification regarding how to handle the display of the scripts is reasonably achievable in this WG.
If so, do we want to have that description in the current documents or start a new document?
If not, my concern is that we try to over-specify and end up in doing the wrong thing. I think we should acknowledge we do not claim to be unambiguous and make sure this could at least be solved in the future without necessarily requiring a bis document.This does not mean we have to leave all issues pending, but we could at least provide some guidance based on the example/examples that come to us. In that sense, the question could be what situations/ examples we have that we want to solve and clarify ?
Feel free to share your thoughts.
Yours,
Daniel
Daniel
On Mon, Aug 28, 2023 at 6:37 PM Rob Sayre <sayrer@xxxxxxxxx> wrote:
On Mon, Aug 28, 2023 at 6:29 AM Robert Stepanek <rsto=40fastmailteam.com@xxxxxxxxxxxxxx> wrote:Hi,I'm still not convinced that there is something Bidi-specific to add to this specification, other than what Unicode standard and the current specification already define.I am also not convinced, but perhaps some concrete examples might help. This technique worked well with addresses (which now look fine to me, although they might need refinements in the future). There, I can see some cases where the correct behavior is only implied, but nothing wrong.I'm pretty familiar with RTL/LTR and whitespace, as Tweets are more difficult to write in many languages. They're much nicer to write in Western languages, since some entities (at-handles, hashtags, scheme-less URLs) appear in free text. The JSContact format is much more structured, so I don't really understand the concern here. Is there a specific i18n concern that is wrong? Not rhetorical, really asking.We could take this example:Does the spec cover it well? I think it's ok, although not very detailed. When I look at the definition:"uri: String (mandatory). The resource value. This MUST be a URI as defined in Section 3 of [RFC3986] and updates."It seems that "updates" could clearly allow this URL. How far does it need to go? I think the authors should decided the amount of ambiguity they're willing to tolerate.thanks,Rob* 1988 Nobel Prize for Literature:
Daniel Migault
Ericsson
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
