Skip to content

RFC URL note has lost its context #1726

Closed

Description

@mattgarrish

As noted in #1725, this note has lost its meaning with recent changes to the URL standard:

Some language specifications reference Requests For Comments that preceded [URL], in which case the earlier RFC applies for content in that language.

This used to be a note about RFC3987, in which case it was a caution that you can't use internationalized IRIs if only RFC3986 or earlier are allowed by a format.

I suppose this is still true -- just because we talk using URL standard language doesn't make the URL standard applicable to other formats that don't reference it. But perhaps we can make this clearer and also, as @iherman noted, find a better position for it so we can make it clear it applies to the whole section.

Activity

  1. iherman commented on Jun 30, 2021

    @iherman
    Member

    The only format where this may apply today is SMIL. All the others, I guess, rely on the URL spec...

    If that is indeed the case, we could move this note to §1.3.4, and that is it...

  2. mattgarrish commented on Jun 30, 2021

    @mattgarrish
    MemberAuthor

    The only format where this may apply today is SMIL. All the others, I guess, rely on the URL spec...

    I believe the only format that references the URL standard is HTML. SVG2 references RFC3987. MathML 3 mentions URIs but doesn't reference any standard and the 4 draft references RFC 3987.

    But, in any case, we have to consider the extensibility of EPUB, too, even if it's an un(der)-used feature.

  3. iherman commented on Jun 30, 2021

    @iherman
    Member

    SVG2 references RFC3987

    Well, SVG2 references both :-)

    MathML 3 mentions URIs but doesn't reference any standard and the 4 draft references RFC 3987

    For all new specs there is an informal requirement, afaik, to refer to the URL spec, unless there is a good reason not to. Ie, I would expect this issue to go away...

    We could move the note to §1.3 as a general note.

  4. mattgarrish commented on Jun 30, 2021

    @mattgarrish
    MemberAuthor

    We could move the note to §1.3 as a general note.

    I'm not sure about a note, but I suppose we could try to shoehorn it into a statement about the relationship to the URL standard. So maybe a new section like:

    1.3.5 Relationship to URL

    This specification refers to the [URL] standard for terminology and processing related to URLs expressed in EPUB Publications. It is anticipated that new and revised Web formats will adopt this standard, but until then this may put this specification in conflict with the internal requirements for some formats (e.g., valid relative paths), specifically with respect to the use of internationalized URLs. If a format does not allow internationalized URLs (i.e., URLs must conform to [RFC3986] or earlier), that requirement takes precedence within those resources.

    But it still feels like we're weaseling our way around a normative requirement with the last sentence, which is the crux of the original note, too.

  5. iherman commented on Jul 1, 2021

    @iherman
    Member

    We could move the note to §1.3 as a general note.

    I'm not sure about a note, but I suppose we could try to shoehorn it into a statement about the relationship to the URL standard. So maybe a new section like:

    1.3.5 Relationship to URL
    This specification refers to the [URL] standard for terminology and processing related to URLs expressed in EPUB Publications. It is anticipated that new and revised Web formats will adopt this standard, but until then this may put this specification in conflict with the internal requirements for some formats (e.g., valid relative paths), specifically with respect to the use of internationalized URLs. If a format does not allow internationalized URLs (i.e., URLs must conform to [RFC3986] or earlier), that requirement takes precedence within those resources.

    But it still feels like we're weaseling our way around a normative requirement with the last sentence, which is the crux of the original note, too.

    I do like the idea of the separate section.

    As for "weaseling": the problem is that we may be facing 'living standards', which means that formats, as implemented and deployed, may be ahead of the normative equivalents. (SVG2 is probably in such a state.) If we put a MUST in the last sentence, we may artificially restrain authors. I would propose to leave it as in your proposed text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    EPUB33Issues fixed in the EPUB 3.3 revisionSpec-EPUB3The issue affects the core EPUB 3.X Recommendation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions