Re: Fwd: I-D Action: draft-msporny-d-langtag-ext-00.txt

--===============4245910664327017581==
Content-Type: multipart/alternative; boundary="00000000000048570a058a0dda1a"

--00000000000048570a058a0dda1a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 29, 2019 at 3:20 AM Martin J. D=C3=BCrst <[email protected]=
p>
wrote:

Again a small issue. My personal understanding is that directionality is
> needed only for mixed directional stuff, and that's as in mixing LTR and
> RTL. Vertical writing is at a higher level.
>

Bidirectionality does in fact exist in vertical writing:  when a horizontal
script
is embedded into CJK or Mongolian (which are written downwards),
Latin and similar scripts appear rotated 90 degrees clockwise and are
written downwards also, but Arabic appears rotated 90 degrees
counterclockwise and is written and read upwards.

(This means that in Arabic in Mongolian, the ancestral Aramaic letters
that underlie Mongolian are upside down from the Arabic perspective.
Mongolian writing evolved from RTL writing by turning the page;
it is common for RTL writers to write vertically while still reading
horizontally.)


>> 5. Given #4, the lack of a registry for the proposed extension, or
> >> even the mention of one, is a significant problem. The set of exactly
> >> 3 values associated with this extension ('ltr', 'rtl', and 'auto')
> >> would be fixed; adding to it would require updating the RFC, which is
> >> much more work than updating a registry.
>
> > Sure, we can add a registry, I can make that change in the next version
> > once it becomes clear that the proposal has merit and won't be rejected
> > by this or the W3C i18n community.
>
> This is again a small issue. I think it's good to have a registry if
> additions can be easily envisioned, but I can't imagine the need for any
> additions soon. And please note that an updating RFC could essentially
> only contain the new tags. It doesn't have to repeat the text in the
> original RFC.
>
>
> >> Without these issues being addressed in a satisfactory way, I would
> >> lobby IETF not to approve this I-D.
> >>
> >> I don't see that there is any reason to approve it, given that it is,
> >> as far as I can tell, completely unnecessary and would just
> >> complicate implementer's lives to no good end.
> >
> > Given the new information above (links to use cases, background
> > discussion), are you still of the opinion that there is no need for the
> > extension?
>
> The extension might be okay if your community can convince us that this
> extension will be strictly limited to those formats (and instances)
> where it's really needed, and that it's stripped or transferred to other
> syntactic elements (e.g. dir attribute for HTML) when that's more
> appropriate.
>
> Regards,   Martin.
> _______________________________________________
> Ietf-languages mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-languages
>

--00000000000048570a058a0dda1a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 29, 2019 at 3:20 AM Marti=
n J. D=C3=BCrst &lt;<a href=3D"mailto:[email protected]">[email protected]=
ama.ac.jp</a>&gt; wrote:<br></div><div dir=3D"ltr" class=3D"gmail_attr"><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">Again a small issu=
e. My personal understanding is that directionality is <br>
needed only for mixed directional stuff, and that&#39;s as in mixing LTR an=
d <br>
RTL. Vertical writing is at a higher level.<br></blockquote><div><br></div>=
<div>Bidirectionality does in fact exist in vertical writing:=C2=A0 when a =
horizontal script</div><div>is embedded into CJK or Mongolian (which are wr=
itten downwards),</div><div>Latin and similar scripts appear rotated 90 deg=
rees clockwise and are</div><div>written downwards also, but Arabic appears=
 rotated 90 degrees</div><div>counterclockwise and is written and read upwa=
rds.</div><div><br></div><div>(This means that in Arabic in Mongolian, the =
ancestral Aramaic letters</div><div>that underlie Mongolian are upside down=
 from the Arabic perspective.</div><div>Mongolian writing evolved from RTL =
writing by turning the page;</div><div>it is common for RTL writers to writ=
e vertically while still reading</div><div>horizontally.)</div><div><br></d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt;&gt; 5. Given #4, the lack of a registry for the proposed extension, or=
<br>
&gt;&gt; even the mention of one, is a significant problem. The set of exac=
tly<br>
&gt;&gt; 3 values associated with this extension (&#39;ltr&#39;, &#39;rtl&#=
39;, and &#39;auto&#39;)<br>
&gt;&gt; would be fixed; adding to it would require updating the RFC, which=
 is<br>
&gt;&gt; much more work than updating a registry.<br>
<br>
&gt; Sure, we can add a registry, I can make that change in the next versio=
n<br>
&gt; once it becomes clear that the proposal has merit and won&#39;t be rej=
ected<br>
&gt; by this or the W3C i18n community.<br>
<br>
This is again a small issue. I think it&#39;s good to have a registry if <b=
r>
additions can be easily envisioned, but I can&#39;t imagine the need for an=
y <br>
additions soon. And please note that an updating RFC could essentially <br>
only contain the new tags. It doesn&#39;t have to repeat the text in the <b=
r>
original RFC.<br>
<br>
<br>
&gt;&gt; Without these issues being addressed in a satisfactory way, I woul=
d<br>
&gt;&gt; lobby IETF not to approve this I-D.<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t see that there is any reason to approve it, given that=
 it is,<br>
&gt;&gt; as far as I can tell, completely unnecessary and would just<br>
&gt;&gt; complicate implementer&#39;s lives to no good end.<br>
&gt; <br>
&gt; Given the new information above (links to use cases, background<br>
&gt; discussion), are you still of the opinion that there is no need for th=
e<br>
&gt; extension?<br>
<br>
The extension might be okay if your community can convince us that this <br=
>
extension will be strictly limited to those formats (and instances) <br>
where it&#39;s really needed, and that it&#39;s stripped or transferred to =
other <br>
syntactic elements (e.g. dir attribute for HTML) when that&#39;s more <br>
appropriate.<br>
<br>
Regards,=C2=A0 =C2=A0Martin.<br>
_______________________________________________<br>
Ietf-languages mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Ietf-languages=
@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ietf-languages" rel=3D"nor=
eferrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/ietf-langu=
ages</a><br>
</blockquote></div></div>

--00000000000048570a058a0dda1a--


--===============4245910664327017581==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf-languages mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-languages

--===============4245910664327017581==--