Aw: Re: Re: [EXTERNAL] Re: External Link Symbol

[Peter Constable]

Non-use of external files is a stated requirement for this context. But it does not state any requirement of a character code to display an icon for external links, and you can review the HTML version of RFC 7992<https://www.rfc-editor.org/rfc/rfc7992.html> to see that it does not use any such icons. In conclusion, RFC 7992 does not provide any argument for UTC to encode a character for an external link icon.


Peter

From: Asmus Freytag <asmusf at ix.netcom.com>
Sent: Thursday, April 18, 2024 10:32 AM
To: Peter Constable <pgcon6 at msn.com>; Marius Spix <marius.spix at web.de>
Cc: unicode at corp.unicode.org
Subject: Re: Aw: Re: Re: [EXTERNAL] Re: External Link Symbol

In this context it is interesting that RFC7992 suggests use of a character code and, incidentally, makes the case that there are use-cases where reliance on external images is explicitly ruled out.

This underscores the "chicken-and-egg" problem we so often encounter in character encoding. Unless a character is encoded, it can't be used in a text-only environment.

In this particular case, my reading would be that there's nothing inherently favoring an image-only solution. It just happens that this was the only way to go in early implementations, but as RFC7992 reminds us, there are use cases where that is not an option.

As a result, as I wrote in an earlier part of this thread, I can't get the warm and fuzzies about applying the "app iconography" principle here. Particularly not for something that always appears in connection with and part of a text block. There are many other examples that are much more removed from text and to which that principle is more properly applicable.

A./


On 4/18/2024 10:13 AM, Peter Constable wrote:
> If I were a submitter, I would treat something like the citation of RFC7992 then not as something that "settles" an encoding question, but one that calls for further research to see whether that particular convention is found in (enough) other places to help reach a decision.

Completely agree with that.

However, there is another factor in this that UTC will consider and _has_ considered: is the symbol used in public text data interchange. Wrt external link symbol, UTC has previously decided that this falls into the general class of symbols used in app iconography and that that evidence based on such usage is not sufficient for encoding as a textual character.


Peter

From: Asmus Freytag <asmusf at ix.netcom.com><mailto:asmusf at ix.netcom.com>
Sent: Wednesday, April 17, 2024 5:56 PM
To: Peter Constable <pgcon6 at msn.com><mailto:pgcon6 at msn.com>; Marius Spix <marius.spix at web.de><mailto:marius.spix at web.de>
Cc: unicode at corp.unicode.org<mailto:unicode at corp.unicode.org>
Subject: Re: Aw: Re: Re: [EXTERNAL] Re: External Link Symbol

This spells out what I tried to imply by warning against overinterpreting this example. However, whether something is a normative specification, and the limits of its normative scope is always only one aspect. Another aspect is whether it represents a record of somebody's explicit convention for what to do for a given feature, such as "anchor" links in the current example.

Having a written convention that documents intent is preferable over relying on mere observation, for example, noticing that certain documents or certain platforms just happen to behave in a certain way. But, on it's own, just because something is written down is certainly not enough to suggest that the convention is common, let alone universal.

From Unicode's perspective, a convention does not have to be normative for general purpose documents to be taken into account in making informed encoding decisions. The degree to which it is followed in practice (both in its original domain as well as in analogous cases) is usually more important.

If I were a submitter, I would treat something like the citation of RFC7992 then not as something that "settles" an encoding question, but one that calls for further research to see whether that particular convention is found in (enough) other places to help reach a decision. Alternatively, it might serve as a data point for the conclusion that there's no single convention (with further research needed to find out whether this represents a case of a small number of alternate coexisting conventions, or the case of something where the real world hasn't settled on anything).

A./

On 4/17/2024 5:32 PM, Peter Constable wrote:
Let’s be clear: all that RFC 7992 is doing is documenting the conventions used in the non-canonical HTML versions of IETF RFCs. Unless in some other context there is a specification that normatively references RFC 7992, it has no real import beyond the HTML versions of IETF RFCs.


Peter

From: Unicode <unicode-bounces at corp.unicode.org><mailto:unicode-bounces at corp.unicode.org> On Behalf Of Asmus Freytag via Unicode
Sent: Monday, April 15, 2024 7:35 AM
To: Marius Spix <marius.spix at web.de><mailto:marius.spix at web.de>
Cc: unicode at corp.unicode.org<mailto:unicode at corp.unicode.org>
Subject: Re: Aw: Re: Re: [EXTERNAL] Re: External Link Symbol

On 4/15/2024 6:55 AM, Marius Spix wrote:
The pilcrow sign is offically mentioned in RFC 7992. See section 5.2. So I would consider it the conventional representation for anchor links.


I would agree that it is "a convention" for representation of anchor links. It happens to work for English, as the pilcrow sign conventionally means "paragraph" and the intent in RFC7992 is to provide links to all paragraphs.

However, the formatting of RFCs provided as HTML is a different beast from generic prescription for formatting all HTML documents. So this should not be over interpreted.

A./

Gesendet: Freitag, 12. April 2024 um 18:46 Uhr
Von: "Asmus Freytag via Unicode" <unicode at corp.unicode.org><mailto:unicode at corp.unicode.org>
An: unicode at corp.unicode.org<mailto:unicode at corp.unicode.org>
Betreff: Re: Aw: Re: [EXTERNAL] Re: External Link Symbol
The first and last choice are arguably not the most conventional representations for these. They are, at best, fallbacks.

A./

On 4/12/2024 12:31 AM, Marius Spix via Unicode wrote:
For all these types of links existing characters can be used:

anchor links: U+00B6 ¶ PILCROW SIGN
local links: U+1F517 🔗 LINK SYMBOL
broken links (also known as red-links): U+26D3 U+200D U+1F4A5 CHAINS + ‍ZERO WIDTH JOINER + COLLISION SYMBOL
external links: U+2192 → RIGHTWARDS ARROW

Gesendet: Donnerstag, 11. April 2024 um 21:05 Uhr
Von: "Asmus Freytag via Unicode" <unicode at corp.unicode.org><mailto:unicode at corp.unicode.org>
An: "Tom Moore" <tom.moore at microsoft.com><mailto:tom.moore at microsoft.com>, "Sławomir Osipiuk" <sosipiuk at gmail.com><mailto:sosipiuk at gmail.com>, "Asmus Freytag via Unicode" <unicode at corp.unicode.org><mailto:unicode at corp.unicode.org>
Betreff: Re: [EXTERNAL] Re: External Link Symbol
On 4/11/2024 11:47 AM, Tom Moore wrote:
> Then multiply that by 2, for links that navigate current tab vs. request to open a new tab.

Is there a link to samples for all of these as used in practice, or is
this just a theoretical distinction?

A./

>
> -----Original Message-----
> From: Unicode <unicode-bounces at corp.unicode.org><mailto:unicode-bounces at corp.unicode.org> On Behalf Of Slawomir Osipiuk via Unicode
> Sent: Thursday, April 11, 2024 9:28 AM
> To: asmusf <asmusf at ix.netcom.com><mailto:asmusf at ix.netcom.com>; Asmus Freytag via Unicode <unicode at corp.unicode.org><mailto:unicode at corp.unicode.org>
> Subject: [EXTERNAL] Re: External Link Symbol
>
> There are actually three kinds of links that are distinguishable from each
> other:
>
> - A link to a different location in the current document (anchor link/jump
> link)
> - A link to a resource on the same network/domain as the current document (local link/relative link)
> - A link to a resource on a different network (external link)
>
> All those can appear as symbols, used contrastively, within a run of text.
> I'm very surprised these haven't already been encoded and that there is any controversy. The consortium doesn't care much for precendent, but come on, we have "play"and "eject" symbols encoded!










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20240419/826fe304/attachment-0001.htm>