Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2141bis: Section 3.3.2 q-component clarification #2

Closed
MelindaShore opened this issue Dec 23, 2014 · 4 comments
Closed

2141bis: Section 3.3.2 q-component clarification #2

MelindaShore opened this issue Dec 23, 2014 · 4 comments

Comments

@MelindaShore
Copy link
Owner

From John:

In section 3.3.2 on q-component, it seems reasonable to add a
bit of explanation, thereby providing some protection from
people who might assume they know what 3986 says without
checking it (especially given the ABNF issues with that
document). I propose something like:

"Note that "?" is not a special character after its
first instance introduces a q-component (assuming one is
allowed by the namespace). "?" appearing later in a
q-component or in an f-component does not require
%-escaping except as required on a per-namespace basis."

Is that roughly correct? What we want?

There is also another issue with that paragraph. Given the
"syntax only" principle, it is not clear that unquoted "?" must
be prohibited from appearing in the NSS and/or p-component (if
we think that is distinct). The argument for prohibiting it is
potential confusion. The argument for allowing it is that it
might be needed for externally-defined name spaces for which
%-encoding would either be clutter or actually problematic.

@MelindaShore MelindaShore changed the title Section 3.3.2 q-component clarification 2141bis: Section 3.3.2 q-component clarification Dec 23, 2014
@klensin
Copy link
Collaborator

klensin commented Jan 21, 2015

2015-01-21: I think this one is settled unless someone complains on-list. However, since there are two (or maybe three) substantive issues hidden in this, I have put a placeholder into the text (as of -09c) rather than changing it. Those issues are:

(0) Does 3986 disallow "?" from appearing in (without %-encoding) and should we say something about that? Given that the very clear text in 3986 managed to confuse Andy and has confused a lot of others, the answers are pretty clearly "it doesn't" and "yes, we should say something". A note to that effect is now in -09c.

(1) Should we disallow "?" from appearing within a even though 2141 does not require that? I think the answer is "no reason to do that", but it may be worth further confirming that with the WG..

(2) Should we say something about embedded question marks as delimiters for name-value pairs? In my personal capacity, I feel quite strongly that the answer should be "yes", but haven seen nearly enough clear support for that view to starting changing the text.

See http://www.ietf.org/mail-archive/web/urn/current/msg02725.html, several notes from probably a year or more ago, and some pieces of I-Ds that I can locate and drag out if needed.

@klensin
Copy link
Collaborator

klensin commented Mar 9, 2015

Text has been clarified to make it clear that "?" is allowed, without encoding, within q-components (after the question mark that introduces those components) and f-components. There have been no substantive comments about any of the other issues identified above.

@klensin
Copy link
Collaborator

klensin commented Apr 23, 2015

Above clarifications are present in 2141bis-11. The text may need further work if q-component is subdivided, e.g., along the lines of Keith's "??" proposal, but I'm starting a separate tracker entry for that, so this one can probably be closed.

@klensin
Copy link
Collaborator

klensin commented Apr 23, 2015

See tracker item #13, '"Component" Information associated with URN processing versus to be passed to objects, URLs, etc.', for the "??" proposal and it context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants