Opened 8 years ago

Closed 8 years ago

#88 closed defect (worksforme)

A number of ABNF issues in 3987bis

Reported by: evnikita2@… Owned by: draft-ietf-iri-3987bis@…
Priority: major Milestone:
Component: 3987bis Version:
Severity: - Keywords:
Cc: evnikita2@…

Description

From http://lists.w3.org/Archives/Public/public-iri/2011Aug/0039.html:


Section 2:

ipath-empty = 0<ipchar>

This assumes that <ipchar> is RFC 5234 <prose-val>, which it isn't.
Please see similar Erratum 2033 for RFC 3986
(http://www.rfc-editor.org/errata_search.php?eid=2033) and Erratum 2846
for RFC 5092 (http://www.rfc-editor.org/errata_search.php?eid=2846); I
believe there are more, though. Please consider changing to:

ipath-empty = ""

Ibid:

path-sep = "/"

... and use of <path-sep> in different <path-...> productions. This is
the issue of readability; what we have in RFC 3987 is better, IMO. This
could be useful if there were two or more possibilities for <path-sep>,
but not here. Ibid:

iquery = *( ipchar / iprivate / "/" / "?" )

ifragment = *( ipchar / "/" / "?" )

Having compared these two productions, I'd like to ask whether there is
some reason for not allowing <iprivate> in <ifragment>?

Change History (2)

comment:1 Changed 8 years ago by masinter@…

ipath-empty = 0<ipchar>
maybe be redundant, but it is harmless.

using path-sep as a separate non-terminal at least lets you talk about the possibility of, say, adding "\".

iquery allowing iprivate doesn't add value and adds confusion.

allowing ifragment question is still open, 12/27 editor meeting couldn't decide (ran out of time).

comment:2 Changed 8 years ago by masinter@…

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

(a) changed ipath-empty as suggested. (this part fixed)

(b) did not change path-sep to eliminate it; there is at least some possibility that some specifications might want to allow \ as path-sep in defining a new very-non-legacy-extended-URI-thingie or some such (such as HTML); in any case, leaving it as a semantic production seems harmless.

(c) did not allow iprivate in iquery:

The reason why iprivate is allowed in iquery and not in ifragment is that a query component is part of a very specific workflow of filling out a form and sending it back for specific processing, while fragments have a much wider profile of interoperability they require. Originally, iprivate wasn't allowed at all, but there were specific, credible use cases where they made sense in queries. There have not been any use cases demonstrated where this is true for fragments.

So: status change is, for three reports: one fixed, two won't fix. Can't say that in tracker, so this is now marked as 'worksforme'.

Note: See TracTickets for help on using tickets.