I'm trying to follow up Philippe's considerations below and in earlier
postings - assuming that & is a reserved character (see my footnote on that
at the bottom of my posting):
* Philippe's initial issue was "that some URIs with reserved characters
aren't representable by QCodes", and an example was
* then Philippe wrote in a later email: " The problem is that when resolving
a QCode, the reserved characters in the code must be percent encoded (per
the current wording), which means that you will never get back, for example,
the "&" in the URI shown above (you'll get back %26 instead)."
Based on the Processing Model in 10.2.1.2 of the Specs document my view is:
Already at the time of defining a Scheme URI the creator of this URI has to
consider encoding. Reason: the Scheme URI as such may deliver a full CV -
therefore it must be a valid URI.
Let's assume this should be a Concept URI - as simple string (be aware of
the & in 2&23)
And the scheme URI should go from left to the = to the right of "id".
As the & in 2&23 is NOT a delimiter it must be encoded and the Scheme URI
http://example.com/people?group=2%2623&id= ... and as Alias let's define
If the code of the concept is 12345 then the QCode is pers1:12345
Resolving this QCode to a Concept URI should make
* then Philippe wrote in his email of 30/12 about what part of the G2
Processing Model is a problem: " In my view, it's in step 2 of
This step says for processing a resolved QCode:
"Check if any Reserved Characters (see RFC 3986 section 2.2 ) are
included based on the used URI
scheme. In particular check for the reserved characters of the http scheme.
If such characters are
used apply percent-encoding as per RFC 3986."
I agree this directive is a bit confusing - at this point in the Processing
Model - as by the example above:
- the & in 2&23 is already percent-encoded
- the & before the "id" is a delimiter and therefore must not be
percent-encoded - but this cannot be definitely known by the receiver.
**Conclusion**: the Processing Model in the Spec document should be
rearranged in a way that the responsibility for percent-encoding has to be
taken by the creator of a Concept URI.
The only facet which should be discussed: is it required to percent-encode
also the code-part of a QCode.
Let's change the code based on the example above to 12&34, the QCode is
Resolving this QCode makes http://example.com/people?group=2%2623&id=12&34 -
but the & in 12&34 is not a delimiter, therefore must be encoded. Could this
action be moved to the receiver as a code is - by my understanding - always
a "component" in RFC 3986 terms and thus requires encoding of reserved
The reason for that is simple: there are vocabularies which exist for a
long time with codes which were defined without any knowledge about URI
syntax and the RFC 3986. Therefore a code like 12&34 could be widely known
and changing it to 12%2634 would cause a lot of confusion.
Therefore the responsibility for percent-encoding in the Processing Model
- with the creator of the Scheme URI for the Scheme URI
- with the receiver and processor of a QCode for the code part, he can
assume that the scheme URI is already percent-encoded as required.
But there is still a tripwire: the creator of a CV MUST NOT percent-encode
codes - or MAY the creator percent-encode?
If the MUST NOT applies a code like 12%2634 must be percent-encoded to
12%252634 by the receiver.
But what action should be taken by the receiver if the MAY rule applies? The
pure string 12%2634 does not tell if the % comes from percent-encoding or
The final conclusion has to be applied also to section 13.8 of the
Implementation Guide as it currently tells contradictions, sorry:
That reserved characters in codes must be encoded by the provider, but also
claims that a QCode may be "fc:#3FTSE" as the # in the code will be encoded
by the receiver.
What do you think?
This "reserved purpose" is exactly causing me headaches as I was not able to
find an *explicit* definition that e.g. & has a purpose which makes it a
reserved character for the http URI scheme.
I've emphasized *explicit* as the http RFC 2616 doesn't even mention &, on
the other hand the URI RFC 3986 includes & into its - potential - reserved
characters  but says the state of being a reserved character is actually
defined by the specifications of the different URI schemes. But as just
said: the specification of the http scheme doesn't even mention the &
character. So do we have to build on practical experience combined with
feelings from the guts or written specifications?
> -----Original Message-----whatI
> From: email@example.com [mailto:newsml-
> firstname.lastname@example.org] On Behalf Of Philippe Mougin
> Sent: Wednesday, January 04, 2012 9:38 AM
> To: email@example.com
> Subject: [newsml-g2] Re: URI and qcodes - does some one has examples and
> documentation ?
> --- In firstname.lastname@example.org, misha.wolf@... wrote:
> > It seems to me that:
> > - an "&" has a reserved purpose in the query component of a URI
> > - when it is being used for that purpose it should *not* be percent-
> In the query component, & and %26 do not mean the same thing at all. An
> application that mint an URI will use either & or %26 depending on the
> meaning it wants to give to that URI.
> This is why percent encoding of reserved characters (where they have a
> reserved purpose) can only be done meaningfully by the application
> producing the URI.
> As far as QCodes are concerned, percent encoding can't be done
> meaningfully at QCode resolution time (which is, in my understanding,
> the G2 spec currently specify): it is too late. Instead, it should happenis when
> an application produce a QCode (i.e., write it down in a NewsL-G2
> document). This is when percent encoding the code can be done.
> Any member of this IPTC moderated Yahoo group must comply with the
> Intellectual Property Policy of the IPTC, available at
> http://www.iptc.org/goto/ipp. Any posting is assumed to be submitted
> under the conditions of this IPTC IP Policy.
> Yahoo! Groups Links