obsoleting 3986 -- what would it look like?

Initially as a thought experiment, I've started to sketch out what it would look like to obsolete 3986 (URI)
with a document that combined it with 3987 (IRI), reverts to the "URL" name, and gave updated parsing advice.

Doing so is pretty ambitious, of course, and likely to lead to all sorts of controversies, but I thought I'd
give it a try.

*  how much of the introductory and explanatory material from 3896 and 3897 to retain. While it's
philosophically and historically interesting, it's also a fertile ground for philosophical debates
over whether http://larry.masinter.net#the_person could  identify, locate, or name me rather than a
paragraph of my home page. So I'm tempted to leave all that behind.
* how much of the historical reasons for distinguishing between URIs and IRIs to leave. Again, it's
interesting and useful material, but less so for practitioners who just want to know what a URL is and how to
use it.
  My temptation at this point is to leave out most of the explanatory material, and just put appendixes for
URI, IRI and LEIRI which explain them as prior syntactic restrictions which are still supported by older
protocols (including HTTP 1.x). Will HTTP 2.0 support UTF-8 URLs?
* Include URNs? I'm tempted to include at least a pointer to URNbis, but I'm not sure which one.
* I'm having trouble resisting the temptation to put a stake into the httpRange-14 by removing any basis for
support of using http URLs to "mean" abstractions or people. Right now I'm considering putting that in a
"URLs and Semantic Web" appendix.
* I'll accept sincere offers of co-authorship as long as you're willing to accept the requirements that to
obsolete 3986 we need to address current use cases that make reference to 3986, 3987, etc.

<abstract>
  <t>Uniform Resource Locators (URL) are compact strings which form a
  namespace used as identifiers.  The URL namespace is federated:
  there are URL schemes, each with its own semantics and syntactic
  restrictions, and a registry of scheme names.  A relative URL is an
  abbreviated form which can be combined with a base URL to form a new
  URL (relative resolution).  Previously, the terms "Unform Resource

Found "in the wild": 'readability' URI scheme

This posting introduces a URI scheme (they call it a "URL") 
"readability", connected with the Readability tool for reformatting 
web content in a more readable way:

http://blog.readability.com/2012/10/new-ios-developer-tools/

The way they define it seems to be against some of the standards, in 
particular for its misuse of the "//" part, which many seem to regard 
as some sort of decorative flourish on the scheme name, but which is 
actually only supposed to introduce an authority segment, none of 
which seems to exist in this URI type.

--

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

URI template variable names vs URI unreserved characters

Hi,

I am trying to use URI templates to describe an existing API. The api has parameters which
include hyphens "-".  URI template variable names disallow hyphens, forcing them to be
% encoded.

Why should hyphens be excluded?  They don't seem to have special meaning in templates
and they are unreserved in URIs.
http://tools.ietf.org/html/rfc3986#section-2.3
http://tools.ietf.org/html/rfc6570#section-2.3

It might work out that the resulting URIs are useable, but they are damn ugly,
and it was readability that prompted the hyphens in the first place.

Thanks,
Peter Rushforth

URL parser in JavaScript

FYI,

> As a first step towards properly defining URLs I wrote a web-compatible URL parser in JavaScript: https://github.com/annevk/url
— http://twitter.com/annevk/status/247749394093457408

People added in reply:

>A robust Punycode converter that fully complies to RFC 3492 and RFC 5891, and works on nearly all
JavaScript platforms. 
— https://github.com/bestiejs/punycode.js

and 

> URI.js is a javascript library for working with URLs. It offers a "jQuery-style" API (Fluent Interface,
Method Chaining) to read and write all regular components and a number of convenience methods like
.directory() and .authority().
— http://medialize.github.com/URI.js/

--

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations, Opera Software

ANN: Draft text fragment ontology for NIF 2.0

draft-ietf-6man-uri-zoneid-01.txt

Hi,

The draft "Representing IPv6 Zone Identifiers in Uniform Resource
Identifiers", available in various formats at
https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid/ ,
has passed WG Last Call in the IETF. Before it's submitted
to the IESG, we'd appreciate comments from this list. If you
happen to have seen an earlier version, please do look at the
latest one (-01) which is substantially different.

Please keep the CC's intact or add a CC to <ipv6 <at> ietf.org>.

Also please comment before July 4.

Thanks
   Brian Carpenter

The enc: URL scheme

I've proposed a new URL scheme in the public-html list (as a response to http+aes scheme and video
encryption discussed there):

http://lists.w3.org/Archives/Public/public-html/2012Jun/0094.html

--

-- 
regards, Kornel Lesi¨½ski

URI Templates update

Hi URI people,

Just a few notes regarding URI Templates, since we have an RFC now <http://tools.ietf.org/html/rfc6570>:

* Joe's implementation in Python has been moved to Github, and we've got it up to RFC level 4 conformance. See
<https://github.com/uri-templates/uritemplate-py>. It's also now listed in pypi
<http://pypi.python.org/pypi/uritemplate/0.5.1>. Note that it's still beta-quality; it doesn't do
much in the way of input checking, for example.

* We've also started collecting test cases at <https://github.com/uri-templates/uritemplate-test>.
Right now it includes the examples from the RFC, but we've been talking with other implementers about
adding more; please make a pull request or raise an issue as appropriate. Note that the Python
implementation above uses these for its testing.

* Finally, the list of implementations at
<http://code.google.com/p/uri-templates/wiki/Implementations> has been updated. If you have more
information about one of them, or would like one added, please make a comment there.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

Fw: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt

For those with an interest in the ABNFing of URI who have not seen this on the
IETF uri-review or on ipv6 lists, the question is how to tack an ipv6 zoneid
onto the constructs in RFC3986, while preserving the long standing ipv6 practice
of using a percent character as the separator in this case.

I would suggest follow-up on one of the two afore mentioned lists.

Tom Petch

----- Original Message -----
From: "Bill Fenner" <fenner <at> fenron.net>
To: "Brian E Carpenter" <brian.e.carpenter <at> gmail.com>
Cc: <ipv6 <at> ietf.org>; "Brian Haberman" <brian <at> innovationslab.net>; "S Moonesamy"
<sm+ietf <at> elandsys.com>; <ipv6-chairs <at> tools.ietf.org>
Sent: Tuesday, March 06, 2012 1:08 PM
Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt

On Mon, Mar 5, 2012 at 7:15 PM, Brian E Carpenter
<brian.e.carpenter <at> gmail.com> wrote:
> Carsten,
>
> On 2012-03-06 12:22, Carsten Bormann wrote:
>> On Mar 6, 2012, at 00:00, Brian E Carpenter wrote:
>>
>>> No, I think it's exactly *not* confused on this point. There's
>>> a distinction between the idealised URI and the produced URI;
>>> in the produced URI, "%25" stands for "%" in the idealised URI.
>>
>> Ah, so the ABNF is wrong
>
> I don't believe so. The ABNF does not describe the produced (encoded)
> URI. I have read sections 2.2 and 2.4 of RFC 3986 several times
> before asserting this. Of course I could be wrong, but we are waiting
> for a review from uri-review <at> ietf.org who will hopefully give a
> definitive answer.
>
>> and the (vague) text is meant as I read it first (it can be read in other
ways).
>
> Please indicate exactly which part of the text is ambiguous, and we'll
> change it.
>
>>
>> Replace
>>
>> IPv6addrz = IPv6address [ "%" ZoneID ]
>>
>> by
>>
>> IPv6addrz = IPv6address [ "%25" ZoneID ]
>
> No. In the encoded URI that would end up as %2525. That's exactly the
> trap that RFC 3986 warns against.
>
>>
>>
>>> We have no real choice but to use % since that was chosen years
>>> ago, and that means that the produced URI contains %25.
>>
>> I don't know that. You could use "percent" and that would work, too.
>
> We could use any unreserved symbol, but that would need translation from
> the RFC 4007 format. For example we could just use Z, as in
> http://[fe80::aZen1].
> Or we could use ~: http://[fe80::a~en1].
>
> Would that be less confusing?

Previous joint work between the ipv6 working group and the W3C URI
working group resulted in a decision that did not change the ABNF at
all, in 2 ways:

1. It used the IPvFuture extension mechanism;
2. It used a non-percent character for the separator.

At the time, the URI working group was very concerned about the change
in the ABNF and the use of percent where percent had not previously
been allowed.  Have they changed their position here, or have they not
had a chance to comment on this change yet?

This work was accepted as an ipv6 wg work item around IETF63 (Paris,
2005), but the authors never pushed the document forward due to a lack
of interest in the broader community.  The draft that was adopted by
the wg was

http://tools.ietf.org/html/draft-fenner-literal-zone-01

  Bill
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

http+aes

FYI:

	http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme

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