[i18n-activity] httpapi-linkset comments (#1505)

aphillips has just created a new issue for https://github.com/w3c/i18n-activity:

== httpapi-linkset comments ==
## Proposed comment

https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/

```4.1: The use of non-ASCII characters in the field value of the HTTP "Link" Header field is not allowed.```

This is an accurate statement about HTTP headers in general (and link in specific), but seems out of place here. This document's format can have non-ASCII characters where an HTTP header must resort to encodings/escapes.

```
4.2.4.1: "hreflang": The "hreflang" target attribute, defined as optional
      and repeatable by [RFC8288], MUST be represented by an "hreflang"
      member, and its value MUST be an array (even if there only is one
      value to be represented), and each value in that array MUST be a
      string - representing one value of the "hreflang" target attribute
      for a link - which follows the same model as in the [RFC8288]
      syntax.
```

RFC8288 references the `Language-Tag` ABNF in RFC5646 (i.e. BCP47), but not BCP47's other requirements. It would also serve legibility/usefulness of this spec if BCP47 were called out directly. That is, I'd say:

```
... and its value MUST be an array (even if there is only one value 
to be represented). Each value in that array MUST be string containing 
a well-formed language tag [BCP47] following the same model as in [RFC8288].
```

```
ibid:    *  "title": The "title" target attribute, defined as optional and not
      repeatable by [RFC8288], MUST be represented by a "title" member
      in the link target object, and its value MUST be a string that
      follows the same model as in the [RFC8288] syntax.
```

RFC8288 uses %-encoded text and allows for non-UTF-8 encodings. But there is no reason for this in a JSON file. JSON itself requires UTF-8 as the file encoding, so why not just allow the title to be UTF-8?

```
ibid:   *  "title*": The "title*" target attribute, defined as optional and
      not repeatable by [RFC8288], is motivated by character encoding
      and language issues and follows the model defined in [RFC8187].
      The details of the JSON representation that applies to title* are
      described in Section 4.2.4.2.
```

This uses %-encoded text and allows any encoding (with UTF-8 as the default), but 4.2.4.2 says:

```
   *  The character encoding information as prescribed by [RFC8187] is
      not preserved; instead, the content of the internationalized
      attribute is represented in the character encoding used for the
      JSON set of links.
```

I think this should be explicit and just *say* UTF-8 in place of "the character encoding used for the JSON set of links"

As a meta-point, there is no discussion either here or in RFCs 8288 or 8187 about matching of language tags/ranges. In addition, the language tags for `title`/`title*` are not allowed to repeat, but it should be noted that language tags are not case-sensitive when matching. Also, there is no discussion of whether the array of `hreflang` values is in priority order or should be considered unordered.

## Instructions: 

This follows the process at https://w3c.github.io/i18n-activity/guidelines/review-instructions.html

1. Create the review comment you want to propose by replacing the prompts above these instructions, but **LEAVE ALL THE INSTRUCTIONS INTACT** 

2. Set a label to identify the spec: this starts with s: followed by the spec's short name. If you are unable to do that, ask a W3C staff contact to help.

3. Ask the i18n WG to review your comment.

4. After discussion with the i18n WG, raise an issue in the repository of the WG that owns the spec. Use the text above these instructions as the starting point for that comment, but add any suggestions that arose from the i18n WG. In the other WG's repo, add an 'i18n-needs-resolution' label to the new issue. If you think any of the participants in layout requirements task force groups would be interested in following the discussion, add also the appropriate i18n-\*lreq label(s).

5. Delete the text below that says 'url_for_the_issue_raised', then add in its place the URL for the issue you raised in the other WG's repository. Do NOT remove the initial '§ '. Do NOT use \[...](...) notation – you need to delete the placeholder, then paste the URL.

6. Remove the 'pending' label, and add a 'needs-resolution' tag to this tracker issue. 

7. If you added an \*lreq label, add the label 'spec-type-issue', add the corresponding language label, and a label to indicate the relevant typographic feature(s), eg. 'i:line_breaking'. The latter represent categories related to the Language Enablement Index, and all start with i:.

8. Edit this issue to **REMOVE ALL THE INSTRUCTIONS & THE PROPOSED COMMENT**, ie. the line below that is '---' and all the text before it to the very start of the issue.

---


**This is a tracker issue.** Only discuss things here if they are i18n WG internal meta-discussions about the issue. **Contribute to the actual discussion at the following link:**


§ url_for_the_issue_raised


Please view or discuss this issue at https://github.com/w3c/i18n-activity/issues/1505 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 5 April 2022 16:44:24 UTC