* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #5 (closed defect: fixed)

Opened 5 years ago

Last modified 3 years ago

Separate IRI from "presentation of IRI" as concepts

Reported by: lmm@acm.org Owned by:
Priority: major Milestone:
Component: 3987bis Version:
Severity: - Keywords:
Cc:

Description

editorial: An IRI is a sequence of Unicode characters.
A sequence of glyphs in a font, or a physical representation
such as printed, written, or read out loud is not an IRI,
it is a presentation of an IRI. Make this change consistently
through the draft. For example,

165,167c165,168
< processing by software) and also a presentation element (for display
< and handling by people who read, interpret, coin, or guess them). The
< transition between these roles is more difficult and complex when
---

processing by software) and also as the basis for presentation
(for display and handling by people who read, interpret,
coin, or guess them). The transition between protocol element
and presentation is more difficult and complex when

Change History

comment:1 Changed 5 years ago by lmm@acm.org

continuing to distinguish between "presentation of IRI" and "IRI"

315,316c321,322
< to a protocol element; for example, using a wider range of
< characters.</t>
---

to a protocol element; for example, a sequence of glyphs
in a font.</t>

390,391c396,397
< may be written on paper or read over the radio as well as stored or
< transmitted digitally. The same IRI might be represented as different
---

may be contained within other streams of text or markup which are
encoded in a character encoding. The same IRI might be represented as different

comment:2 Changed 5 years ago by lmm@acm.org

Also, add this section:

570a577,597

<section title="Conversion to and from presentational form" anchor="presentation">

<t>Informally, the general notion of a "URL" is something that can be
written on paper, read aloud, or otherwise represented independently
of any particular character encoding or even a clear sense of
character identity. Such presentations might be recognized by people,
typed in on computer keyboards, or extracted from images by OCR
software. In the case of software specialized for entry of IRIs, it is
recommended that the entry method or recognition method represent the
resulting IRI as a sequence of characters from the UCS normalized
according to Unicode Normalization Form C (NFC, <xref
target="UTR15"/>).</t>

<t>Similarly, the presentation of an IRI or URI to a user
or for visual publication should be done in such a way as
to avoid the worst of ambiguities, false cognates, or spoofing.
The best practices for this kind of conversion are out of
scope for this document.</t>

</section>

comment:3 Changed 5 years ago by lmm@acm.org

Later on, remove this section, as it should be covered:

< <t> In other cases (written on paper, read aloud, or otherwise
< represented independent of any character encoding) represent the IRI
< as a sequence of characters from the UCS normalized according to
< Unicode Normalization Form C (NFC, <xref target="UTR15"/>).</t>

comment:4 Changed 4 years ago by duerst@it.aoyama.ac.jp

From interim teleconference, 2010-10-05:
from a discussion of #23 normalization:

Addison: proposal text: http://lists.w3.org/Archives/Public/public-iri/2010Sep/0039.html
Addison: related to #5: http://trac.tools.ietf.org/wg/iri/trac/ticket/5
Larry: Problem is when to apply normalization.
Larry: replacing the requirement to an advice.
Larry: need to address #5 before #23.
Martin: thinks we have rough consensus. problem is the right wording.
Larry: i think we have some agreement on the direction of the solution for #23,

but the wording will change depending on the resolution of #5

Martin: difficult to explain the difference between presentation and representation.
Larry: disagree with Martin.
Larry: spoofing and phishing is an artifact of the unreliability of IRI <--> presentation
Martin: spoofing part of the security section is the good place to discuss this issue.
Addison: if we don't require normalization, then there is nothing to say except listing

the different kind of normalization.

ACTION: Larry to send proposed text to the list.

comment:5 Changed 3 years ago by masinter@adobe.com

  • Status changed from new to closed
  • Resolution set to fixed

As per editorial session 12/17 w/martin, peter, chris, we will commit set of changes to address this. May need another review pass.

Note: See TracTickets for help on using tickets.