Roy T. Fielding | 4 Feb 01:55 2012

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:

(Continue reading)

Alessandro Angeli | 1 Mar 18:48 2012

Re: data URIs - filename and content-disposition

I will revive this old thread with a proposal, in case this is ever
going to be implemented.

The original proposal is to add support for the FILENAME and
CONTENT-DISPOTION params in the MEDIATYPE part of a "data:" URI.

It evolved into a more generic support for a HEADERS param.

The former has the benefit of simplicity, the latter of flexibility.
But, at least judging from the discussion of the related proposal in the
Firefox bug-tracking system
(https://bugzilla.mozilla.org/show_bug.cgi?id=532230), neither is easily
implemented because of both parsing and handling limitations.

Moreover, both proposals require the definition of a new param (either
CONTENT-DISPOTION or HEADERS) that can be applied to all MEDIATYPEs and
the repurposing of the FILENAME param, which originally only applies to
the Content-Disposition header field and not the MEDIATYPE.

However, as far as I can tell, it is possible to achieve an even more
generic and flexible result than what would be accomplished by the
HEADERS param in a completely standard-compliant way by using the
message/* MEDIATYPE, so that the payload (DATA part) of the "data:" URI
would be a complete message/*, including its header fields.

For example, using message/http, one would have (all in one line):

{data:message/http,HTTP 200 OK|Content-Type:text/plain;charset=utf-8
|Content-Disposition:attachment;filename=%22hello world.txt%22||HELLO
WORLD}
(Continue reading)

sune.jakobsson | 2 Mar 14:05 2012

URI ACR extension

Dear all.

I would like to bring your attention the http://tools.ietf.org/html/draft-uri-acr-extension-04  submission.

Technical summary:

   This URI scheme is intended as an extension to the "tel:"
   scheme but without disclosing the true identity of a reference or a
   user.  The "acr" URI describes an anonymous reference, that can be
   mapped to a resource or a user.  There are multiple situations where
   the true identity of a user or a resources can not be disclosed.  The
   "acr" URI is a globally unique identifier ( "name" ) only; it does
   not describe the steps necessary to reach the user or the device.
   However it can contain a parameter indication what body or
   organisation that could resolve it.  It is intended for privacy
   protection, where a user trusts a translating party, that can route
   or forward the request or message to the true user or resource.

This is an individual contribution, so I need help to bring this to a working group, and hopefully convert it
to a permanent RFC in time.

Open Mobile Alliance is using this on multiple network enablers, to allow anonymous access to API's

Any advice would be helpful. :)

BR Sune Jakobsson

Gannon Dick | 2 Mar 23:48 2012
Picon

Re: URI ACR extension

Hi Sune,

I have a suggestion for the default parameter ...  This should not be null, since then you'll have every data miner east of the Moon trying to hack your scheme.  Rather I suggest http://purl.org/pii/terms/#alpha  (HTML) or http://purl.org/pii/terms/alpha (RDF)  or make up your own URL to oblivion.  It won't stop miscreants, but it will slow down robots nicely.

--Gannon

From: "sune.jakobsson <at> telenor.com" <sune.jakobsson <at> telenor.com>
To: uri <at> w3.org
Cc: Kevin.Smith <at> vodafone.com
Sent: Friday, March 2, 2012 7:05 AM
Subject: URI ACR extension

Dear all.

I would like to bring your attention the http://tools.ietf.org/html/draft-uri-acr-extension-04  submission.

Technical summary:

  This URI scheme is intended as an extension to the "tel:"
  scheme but without disclosing the true identity of a reference or a
  user.  The "acr" URI describes an anonymous reference, that can be
  mapped to a resource or a user.  There are multiple situations where
  the true identity of a user or a resources can not be disclosed.  The
  "acr" URI is a globally unique identifier ( "name" ) only; it does
  not describe the steps necessary to reach the user or the device.
  However it can contain a parameter indication what body or
  organisation that could resolve it.  It is intended for privacy
  protection, where a user trusts a translating party, that can route
  or forward the request or message to the true user or resource.

This is an individual contribution, so I need help to bring this to a working group, and hopefully convert it to a permanent RFC in time.

Open Mobile Alliance is using this on multiple network enablers, to allow anonymous access to API's

Any advice would be helpful. :)


BR Sune Jakobsson





Gmane