URI Template spec has been approved

Hello folks,

It seems that I need to close the loop, since the independent
submission process doesn't feed back here (unlike an open WG).

After a large number of constructive last call comments and
a draft 08 to address them

  http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-08.txt

the spec has been approved by the IESG as a Proposed Standard.
Now we just have to wait for the RFC Editor queue to get final
wording edits and publish it.

A diff from 07 is at

  http://uri-templates.googlecode.com/svn/trunk/spec/draft-gregorio-uritemplate-08-from-7.diff.html

Note that the one substantive change is the processing of
{;list*}, {?list*}, and {&list*} to allow for repeated
parameters with the same name, based on an earlier discussion
here.  Happy implementing.

Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Principal Scientist, Adobe Systems  <http://adobe.com/enterprise>

Begin forwarded message:

URI-Templates: "^" allowed in literals or not?

I have been working on an implementation of URI Templates in C#, and
came upon some ambiguity in the spec. In section 2.1 Literals, the ABNF
includes %x5D-5F in the set for literals, but the comment mentions that
literals should be 'any Unicode character except ... , "^", .. ' but "^" is
%x5E. Is "^" in the set of literals or no?

Thanks in advance,
-pete

ANN: NLP Interchange Format (NIF) 1.0 Spec, Demo and Reference Implementation

Dear all,
we discussed the URI schemes on this list and I wanted to give some 
short feedback, how it turned out.
In a nutshell, I benchmarked if the URLs are stable between Wikipedia 
revisions and it turned out that the context-hash based approach had 
quite high probability (80-90 %) to stay stable between the revisions. 
Details can be found in the technical report.
All the best,
Sebastian

***ANNOUNCEMENT***
The Natural Language Processing Interchange Format (NIF) is an 
RDF/OWL-based format that aims to achieve interoperability between 
Natural Language Processing (NLP) tools, language resources and 
annotations. The core of NIF consists of a vocabulary, which can 
represent Strings as RDF resources. A special URI Design is used to 
pinpoint annotations to a part of a document. These URIs can then be 
used to attach arbitrary annotations to the respective character 
sequence. Employing these URIs, annotations can be published on the Web 
as Linked Data and interchanged between different NLP tools and 
applications.

In order to simplify the combination of tools, improve their 
interoperability and facilitating the use of Linked Data we developed 
the NLP Interchange Format (NIF). NIF addresses the interoperability 
problem on three layers: the structural, conceptual and access layer. 
NIF is based on a Linked Data enabled URI scheme for identifying 
elements in (hyper-) texts (structural layer) and a comprehensive 
ontology for describing common NLP terms and concepts (conceptual 
layer). NIF-aware applications will produce output (and possibly also 

TTLs for templates

Another idea for URI templates

URI scheme best practices

Hello everyone,
I've been reading through RFC 4395 and some of the mailing list
archives. We're working on iOS and Android apps that we'd like to have
be able to respond to URIs in the mail applications of each of those
devices. For example, if we generate a password reset email and send
it to the user and they click on that link in their mail application
we'd like that to fire up our app instead of the web browser.

I recognize that this is a fairly standard thing to do and in reading
through what must be a somewhat memorable thread (fb: URIs?
http://lists.w3.org/Archives/Public/uri/2010Feb/0013.html) I see that
this has been beaten around a bit.

Based on the fb: URIs thread I get the feeling that people wish we
could register with iOS and Android to have our app handle URIs of the
form http://www.eventbrite.com/resetpassword. I'm pretty sure that
this is not possible?

Given that we don't think we can use http and given RFC 4395 we're
planning to use a scheme com-eventbrite-attendee: and generate URIs
like com-eventbrite-attendee:resetpassword?parameters&go&here

Is this the current best practice? Is the intent of 4395 that we
attempt registration of the scheme com-eventbrite-attendee:? I'm happy
to go through the process described in section 5 of 4395 but the
extremely tiny URI scheme registration list almost makes me think that
IANA doesn't want us in there.

Thanks,

Bob

URI templates: commas

Commas don't have a particularly special role in URIs. They are just 1 of 11 characters in the <reserved> set
that are not used as delimiters of the generic URI components.

URI templates (draft-gregorio-uritemplate-06), however, gives commas special meaning. They are the
only <reserved> character that can appear when expanding {var}.

I'm not aware of any reason why URI templates should single out commas for this special treatment.
It simultaneously encourages servers to use commas as separators, while also causing problems for some
servers that have (quite reasonably) chosen to use commas as separators.

Consider a bank server that accepts payment transactions such as:
  https://example.com/pay/{amount},{to},{from},{comment}

The template processor might be a trusted front-end inserting the "from" variable value based on the
authenticated user, but accepting "amount" and "to" values from the user.
This should be able to be safe. But it isn't with the current draft spec.
If the user provides a "to" value that is actually a list [ "me", "victim" ] then the expansion puts the second
"to" value where the bank was expecting the "from" account -- and a fraudulent transaction occurs.

Perhaps the bank could switch to using a different delimiter -- but that rather defeats one of the purposes
of URI templates of being able to match the server's choice of URI structure.

If the server can provide extra information *outside of the template* about which variables are
mandatory, which can or cannot be lists, and which can or cannot be composite values, then it may be able to
avoid these problems. But templates should be usable without those limitations.

Almost any URI structure using commas as delimiters can face problems with even the most basic level 1
templates since the server cannot distinguish a comma from expanding a user-provided value from a comma
that was a literal expression delimiter in the template.

I suggest that commas not be given special treatment by URI templates.
Expanding {var} should only be able to produce <unreserved> and <pct-encoded> characters -- regardless
of the variable values a user provides.

--
James Manger

Uri Templates: Questions on draft-gregorio-uritemplate-06

Hi All,
 i am having trouble reconciling some of the examples in the 06 draft
with both the descriptions of the expansions and the sample
implementation.

The first set hinge on the handling of expansions where named (in the
sense of the table in appendix A) is true. The variable list has the
list value ["red", "green", "blue"]. The example expansions are:

        {;list}        ;list=red,green,blue
        {;list*}        ;red;green;blue
        {?list}        ?list=red,green,blue
        {?list*}        ?list=red&list=green&list=blue
        {&list}        &list=red,green,blue
        {&list*}        &list=red&list=green&list=blue

I don't understand why the expansions of ? and & include list= for
each entry when exploded. The description of the handling for the case
of an exploded list makes no mention of the use of the name, and there
is no separate section (as there is for the unexploded case). Also,
the table makes ; the same as ? and & for named, and yet their
handling appears different. The descriptions in 3.2.7 and 3.2.8 /
3.2.9 are likewise similar. In short, i can't see why the examples
differ, given the rest of the document, i was expecting

        {?list*}        ?red&green&blue
        {&list*}        &red&green&blue

I know these don't look like valid form query or form continuation
strings - am i missing something in the description of ? and & (and
the implementation hints) regarding special handling for the name when
exploded ?

The second case is the examples for the variable foo with string value
"That's right!"

        {foo}        That%27s%20right%21
        {+foo}        That%27s%20right!
        {#foo}        #That%27s%20right!

As far as i can see, the single quote character between the t and the
s is in sub-delims (in section 1.5) between & and (. I don't
understand why it is treated differently to ! which is also in
sub-delims. I would have expected these last two expansions to be:

        {+foo}        That's%20right!
        {#foo}        #That's%20right!

since both + and # have allow U+R, and ', ! (but not space) are
sub-delims and hence reserved.

Thanks in advance for any enlightenment,

 - Robbie

URI templates: comma-separated variable lists

draft-gregorio-uritemplate-06.txt allows a comma-separated list of variables in any expression,
regardless of the expression operator.

However, a list should not be used with 5 of the 8 operators (+ # . / and no operator) because an expansion will
be ambiguous if any variable in the list is undefined. The server cannot tell which value goes with which variable.

Consider if the template "{alpha,beta,gamma}" is expanded to "23,6". The user could have provided
alpha=23 beta=6, or alpha=23 gamma=6, or beta=23 gamma=6 (or beta=[23,6] but that is a separate bug).

A template like "{alpha,beta,gamma}" is almost certainly a mistake by the template author. It only makes
any sense if all the variables are mandatory, but in that case it is clearer to use
"{alpha},{beta},{gamma}" -- with no chance of ambiguity (and simpler lower-level expressions).

I suggest changing the spec ABNF to only allow variable lists with operators that produce name=value pair
(or drop variable lists entirely).

--
James Manger

Fwd: Re: Document fragment vocabulary

uri-templates implementation feedback.

Hi all,

I've finally come round to updating my js implementation to the latest 
state of the spec (that is currently r71 at 
http://code.google.com/p/uri-templates/)

I know this has no official 0.6 label (yet), but since it fixed some 
samples and removed some more requirements (e.g. the 'default') lazy me 
thought this to be an easier goal.

Anyway, here some findings:

[unnamed list expansion for ; matrix-params]
Anyway: I only have one case that made me add some quirk to comply to:
   {;list*}              ;red;green;blue

Without the quirk my implementation produced:
   {;list*}              ;list=red;list=green;list=blue

Well, I obviously don't like quirks, but sentiments aside I am left to 
wonder if the matrix-parameters are not always expected to carry a name?

[encoded names]

If I understood the spec correctly the varspec-names can contain 
pcnt-encoded characters, and should be decoded to translate onto 
context-keys.

Thus the following expansions should work out as listed, right?

>     var context = {
>         "!":  "exclamation-mark",
>         "%21": "encoded exclamation-mark"
>     }
>
>     var testset = {
>         "{!}"   : "{!}",
>         "{%21}" : "exclamation_mark"
>     };
>

[nesting context variables]

The spec doesn't play out dereferencing nested structures by using . (or 
some other notation) between variable-names.

I'm not sure if this on purpose or just a wicked idea from me:

>     var context = {
>         "a.b"       : "value-at-a.b",
>         "x"         : { "y": "value-at-y-via-x"}
>     }
>
>     var testset = {
>         "{a.b}"       : "value-at-a.b",
>         "{x.y}"       : "value-at-y-via-x"
>     };

Dunno if this makes sense to add, but it seems like a fairly easy thing 
to add in the implementation.

On the other hand, it can be overcome by preprocessing the context 
structure (pretty much similar to how we currently would be adding the 
removed 'defaults' behavior, no?)

Note there is a challenge to correctly define 'preference of finding' 
which of possibly multiple matching keys with this approach. "a.b.c" 
might be found at any of: "a.b.c" "a"->"b.c", "a"->"b"->"c", "a.b"->"c"

All for now.
My implementation can be found at 
https://github.com/marc-portier/uri-templates  (The two failing tests 
(src/test/webenv/test.html) at the moment are the ones mentioned just 
above, I'll gladly fix taking into account your responses and 
clarifications.  If time permits I'll try to add some more edge-case tests)

regards,
-marc=