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

Ticket #11 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

dealing with "document character encoding"

Reported by: lmm@acm.org Owned by: masinter@adobe.com
Priority: minor Milestone:
Component: 3987bis Version:
Severity: - Keywords:
Cc:

Description

Browsers use the "document character encoding" when deciding how to encode query parameters. Communicating this well in this document is a problem, does this resolve it?

598,605c625,631
< target="UTR15"/>). In this case, retain the original character
< encoding as the "document character encoding". (DESIGN QUESTION:
< NOT WHAT MOST IMPLEMENTATIONS DO, CHANGE? ) </t>
<
---

target="UTR15"/>). There are some contexts (especially in
web browser contexts with URIs originally constructed as
the result of form processing) where the original
"document character encoding" is needed to properly interpret
the query parameters (see <xref target="webaddress"/>).

</t>

Change History

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

  • Owner set to masinter@adobe.com

What I really want to do here is to say that

  • an IRI is an abstract sequence of UCS or unicode characters
  • what's printed on the side of a bus or read aloud isn't an "IRI" but some presentation of an IRI, and subject to guidelines and warnings because a human is involved as a transcoder (reading or listening and then writing something into an input buffer)
  • what's contained in files in other charcter encodings is not quite an IRI, and also subject to translation rules that depend on the context.
  • The subject of "recognizing and extracting IRIs from plain text" as a special call-out of this translation.

Peter St. Andre wrote:
" Belongs in the processing spec (a.k.a. "Reschke-Weber"), specifically in text about on the topic of pre-processing."

We will need to get the Reschke/Weber/Barth? documents together to describe parsing and preprocessing specifically for HTML?

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

Looking at this item again...

The section "Mapping Query Components" actually does address this. I'm not sure whether the "(pre)processing" may need to describe this in more detail?

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

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

Looking at the bug reported and the comments,

http://tools.ietf.org/html/draft-ietf-iri-3987bis-07#section-3.5

actually seems to do a decent job of saying what needs to happen to query components.

So I'm marking this bug as "fixed".

Note: See TracTickets for help on using tickets.