gmane.org.w3c.uri

Re: obsoleting 3986 -- what would it look like?

Julian Reschke — 2012-11-13T10:48:42

Well hidden, I guess. See <http://xml.resource.org/public/rfc/xml/>.


Yep.

Sources for 3986 and 5234 are at <http://greenbytes.de/tech/webdav/>, 
they use extensions so you'll have to look at 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#clean-for-dtd>.


No, it's not.


You can always ask the RFC Editor whether they have a copy of the XML; 
they should for most RFCs of the last ~7 years.

Best regards, Julian

Re: obsoleting 3986 -- what would it look like?

David Sheets — 2012-11-13T00:54:05

Great! I'll extract a schema and export the same format. I will report
here with deviations as I find them.


I didn't see any RFC XML docs (just tools) at that URL but perhaps I
missed something obvious. I am looking for XML representations of
2141, 3986, 3987, and 5234. Does IETF keep XML documents as canonical
representations? They appear to publish the official standards in
ASCII.

It would be super-cool if <http://tools.ietf.org/html/rfcXXXX> had a
link with "[txt|pdf]" for XML or a <link> in the HTML source for an
XML alternate. This seems dependent on IETF practices w.r.t. draft
conformance requirements. Is use of XML and xml2rfc mandatory? If so,
what needs to be done to expose XML representations for all RFCs?

Thanks,

David

Re: Clarifying the URL Standard goals

Julian Reschke — 2012-11-08T12:26:45

 > ...

That's something we should test (and potentially eliminate) instead of 
making it mandatory.

 > ...

Best regards, Julian

Re: obsoleting 3986 -- what would it look like?

Martin J. Dürst — 2012-11-06T01:14:20


On 2012/11/05 8:29, David Sheets wrote:


The IRI WG has a subversion repository viewable at 
http://trac.tools.ietf.org/wg/iri/trac/browser/draft-ietf-iri-3987bis.


http://www.ietf.org/rfc/rfc2141.txt is "URN Syntax". (No well-known 
email endpoints as far as I can see.)



My guess is that Larry meant RFC 4395 
(http://www.ietf.org/rfc/rfc4395.txt), Guidelines and Registration 
Procedures for New URI Schemes.

Regards,   Martin.

Re: obsoleting 3986 -- what would it look like?

Julian Reschke — 2012-11-05T17:57:56

I hacked an XML export option into Bill Fenner's "BAP" (Bill's ABNF 
parser). Sources at 
<http://trac.tools.ietf.org/wg/httpbis/trac/browser/abnfparser/bap>.


xml.resource.org has some. Are you looking for a specific one?


Best regards, Julian

Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive< at >w3.org from September 2012)

Anne van Kesteren — 2012-11-05T10:31:07

On Mon, Nov 5, 2012 at 10:53 AM, "Martin J. Dürst"
<duerst< at >it.aoyama.ac.jp> wrote:

Alignment with HTML. There's actually another change required for
that, see https://www.w3.org/Bugs/Public/show_bug.cgi?id=19743 for
details. I'm also happy for HTML to change, but it seems to me that
for code points higher than U+007F we should have some kind of
consistent set of rules across syntaxes, unless the the code points
are problematic for that particular format.



I'm not interested in a code-point-by-code-point discussion, just the
bigger picture, and consistency in requirements across the formats we
develop.

Re: obsoleting 3986 -- what would it look like?

David Sheets — 2012-11-04T23:29:22

Hi Larry,

On Fri, Nov 2, 2012 at 12:24 AM, Larry Masinter <masinter< at >adobe.com> wrote:

I am very interested in the aggregation of URI/URN/URL/IRI grammars
and formalization of codepoint translation tables. Does IETF have an
XML vocabulary for expressing ABNF (RFC 5234?) grammars? I am
presently developing machinery for grammar analysis that will be used
to generate reference parsers, serializers, and test suites directly
from the specification(s).

Is there a central repository of RFC XML (RFC 2629) documents? Are you
drafting the neo-URI RFC in a revision control system somewhere?


RFC 2141 is about well-known email endpoints for domains. How is this
related to the structure of identifiers?

RFC 4345 is about RC4 modes for SSH? How is this related? Or which
other RFC was meant?


Great! These strings are so critically important for the future health
of the internet; I would love to see their structures completely and
unambiguously defined.

I'll send more information about my ABNF work when I have it (or
you're welcome to snoop; it's open source). Let me know if there is
anything else I can do to help.

Best regards,

David Sheets

Re: obsoleting 3986 -- what would it look like?

Mark Davis ☕ — 2012-11-04T18:39:52

I really like this idea. It would be far easier to understand and deal
with, both for developers and for users, than the current nomenclature.
I've seen so many problems due to confusion over what is, at heart, the
same concept just with different expressions.

Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**



On Fri, Nov 2, 2012 at 12:24 AM, Larry Masinter <masinter< at >adobe.com> wrote:

Re: obsoleting 3986 -- what would it look like?

Larry Masinter — 2012-11-03T20:59:35

uri should remain as restricted syntax as compatible as possible with 3986 (same strings legal) and iri too. along with leiri, for that matter. but they are depricated in that new protocols should expect the broader range of urls if possible.

Sent from mobile Larry
--
http://larry.masinter.net

Erik Wilde <dret< at >berkeley.edu> wrote:

hello.

On Nov 2, 2012, at 8:27, James M Snell <jasnell< at >gmail.com<mailto:jasnell< at >gmail.com>> wrote:
On Fri, Nov 2, 2012 at 12:24 AM, Larry Masinter <masinter< at >adobe.com<mailto:masinter< at >adobe.com>> wrote:
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.
Seems to be a reasonable effort to undertake... you had me at combining 3986 and 3987. I'll happily help any way I can.

same here, and i think it makes a lot of sense to consolidate things as much as possible. some refactoring, plus some new parts such as the parsing rules. not sure i'd like to deprecate the URI name, which is what i have been using religiously, but in the end, we should pick the name that works best.

* 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.
+1 ... I can't see any reason why the updated spec should delve into any of that.

yes, i agree to this one. any conventions should be left to define and describe for those who want to use them.

* Include URNs? I'm tempted to include at least a pointer to URNbis, but I'm not sure which one.
Not convinced it would be necessary to include but could be wrong.

isn't it really yet another scheme? a little different because it's a scheme for schemes, but it really is nothing but a scheme.

* 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.
Hmm.. not sure this really needs to be touched on at all really. Why not simply focus on the mechanics of the syntax, parsing, and error handling and avoid the semantics completely.

i think avoiding semantics would be the way to go, and the httpRange-14 debate might be one that's best deferred to those layers where people introduce and then need to solve those problems.

* 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.
Happy to help where I can.

same here. it'll be quite a bit of work, but it would be worth it.

cheers,

dret.

Re: obsoleting 3986 -- what would it look like?

Erik Wilde — 2012-11-03T14:35:48

hello.

On Nov 2, 2012, at 8:27, James M Snell <jasnell< at >gmail.com> wrote:

same here, and i think it makes a lot of sense to consolidate things as much as possible. some refactoring, plus some new parts such as the parsing rules. not sure i'd like to deprecate the URI name, which is what i have been using religiously, but in the end, we should pick the name that works best.


yes, i agree to this one. any conventions should be left to define and describe for those who want to use them.


isn't it really yet another scheme? a little different because it's a scheme for schemes, but it really is nothing but a scheme.


i think avoiding semantics would be the way to go, and the httpRange-14 debate might be one that's best deferred to those layers where people introduce and then need to solve those problems.


same here. it'll be quite a bit of work, but it would be worth it.

cheers,

dret.

Re: obsoleting 3986 -- what would it look like?

James M Snell — 2012-11-02T15:27:32

Seems to be a reasonable effort to undertake... you had me at combining
3986 and 3987. I'll happily help any way I can.



+1 ... I can't see any reason why the updated spec should delve into any of
that.



What http 2.0 will support is still up in the air but drawing a line in the
sand with this new spec could help to drive that decision ultimately.



Not convinced it would be necessary to include but could be wrong.



Hmm.. not sure this really needs to be touched on at all really. Why not
simply focus on the mechanics of the syntax, parsing, and error handling
and avoid the semantics completely.



Happy to help where I can.

- James

obsoleting 3986 -- what would it look like?

Larry Masinter — 2012-11-02T07:24:31

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
  Identifier" (URI), "Internationalized Resource Identifier" (IRI) and
  used to designate syntactic restrictions of the URL space.
  </t>
  <t>This specification brings together these defintions into a single
  specification and updates them to match current widespread usage,
  most notably within the World Wide Web global information and
  application system.
  </t>
  <t>This document is part of a set of documents intended to
  replace RFCs 2141, 3986, 3987 and 4345</t>
</abstract>




<section title="Introduction">

<t>
  The concept of a "Uniform Resource Locator" was introduced
  by the World Wide Web global information initiative, whose
  use of the concept dates from 1990, and was described in 
  "Universal Resource Identifiers in WWW" <xref target="RFC1630"/>
</t>

<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
  Identifier" (URI), "Internationalized Resource Identifier" (IRI) and
  used to designate syntactic restrictions of the URL space.
  </t>
<t>
  This specification brings together these defintions into a single
  specification and updates them to match current widespread usage,
  most notably within the World Wide Web global information and
  application system.</t>
<t>
  This specification and its companions "Comparison of URLs" <xref
  target="url-comparison"/> "Guidelines for Bidirectional URLs" <xref
  target="url-bidi-guidelines"/>, "Registration of URL schemes" <xref
  target="url-registration"/> obsolete <xref target="RFC3986"/>, <xref
  target="RFC3987"/>, <xref target="RFC4345"/>.
</t>

<section title="Uniform, Resource, Locate">
    
  <t>The original design of URLs and its various forms intended
   to accomplish many aspects. </t>
  <t><list style="hanging">

    <t hangText="Uniform Meaning">
      The intention is that the same URL means (identifies, names,
      locates) the same thing independent of context.</t>

   <t hangText="Resources unlimited">
     The notion of a resource was not limited in scope, with the idea
     that URLs could be used to locate, identify or name not only
     network accessible services, resources and documents, but also
     people, artifacts, abstractions.</t>
   
   <t hangText="Locate, Identify, Name">
     An identifier embodies the information required to distinguish
     what is being identified from all other things within its scope
     of identification.  A locator embodies the information required
     to find and access the thing being located. A name is a component
     of an identifier assigned and resolved by some authority or
     agent. This specification reverts to the most commonly used
     "Locator" designation. </t>
     <t>The role of URLs as locators, identifiers, and names have often
     been in conflict with the design goal of "Uniform Meaning". Some
     systems may use URLs (and, in particular, HTTP URLs) as identifiers
     for abstractions, this usage is not supported by this specification
     directly.</t>
     <t hangText="Internationalized">

     <t>URLs were originally defined to only consist of characters
     from a limited repertoire of characters, selected from the upper
     and lower case letters A-Z plus a limited set of punctuation
     characters, with the provision that other data (and the coding
     for other characters) could be included via an escape sequence.
     This use was extended in later specifications of
     Internationalized Resource Identifiers <xref target="RFC3897"/>
     to include characters from a much larger repertoire.
     </t>
     <t>This specification specifies parsing and
     processing of arbitrary strings of
     Unicode characters as input, with previous syntactic
     restrictions still required by older systems (URI, IRI)
     specified in appendices.</t>
   </list>
  </t>

Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive< at >w3.org from September 2012)

Anne van Kesteren — 2012-10-25T13:54:43

Correct, that does not mean valid input is similarly relaxed. That is
also not the case for HTML for example. Literally anything produces a
tree of sorts, but far from all input is considered valid.



I aligned it with IRI now, apart from private Unicode ranges. Not
really sure why we should ban them in one place and not in another.


We discussed how to write the algorithms on the WHATWG list before and
again I challenge you to write out your approach and convince the
world it's better. I'm not interested in doing that work for you.

Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive< at >w3.org from September 2012)

Roy T. Fielding — 2012-10-24T19:10:59

As a historical footnote, the term URL was created by the same
BOF that created the Uniform Resource Identifiers working group
at the IETF meeting in July 1992.

The early Web protocol specs had used the term "network address".

The term "Document Identifiers" came from Brewster Kahle and was
later used in a call for proposals by the Coalition for Networked
Information's Architectures & Standards Working Group, which in
turn led to TimBL propose Web addresses as Universal Document
Identifiers for a BOF at IETF 24 (Cambridge, MA).  Somewhere
in that BOF discussion, the URI working group was proposed and
TimBL's proposal was renamed Uniform Resource Locators
to distinguish it from other ideas for URNs
[see IETF 24 proceedings, p.184, and the following link].

 ftp://ftp.ietf.org/ietf/92jul/udi-minutes-92jul.txt

TimBL had originally specified that addresses in HREF could be
provided in full or partial form.  The IETF removed the partial
form, leading to all sorts of bad decisions regarding syntax,
and so I revived it in 1994 as Relative URLs [RFC1808].  That
spec is the only one that came close to defining what Anne
is trying to do here -- a single parsing standard for
potentially relative references. 

It is easy to claim that the merging of syntax specs that
created RFC2396 lost some value when the parsing standard was
replaced by a non-normative appendix.  However, it was discussed
extensively at the time, including with the browser developers,
and there was simply nothing common enough to make standard.
The best I could do for 2396 and 3986 was to include a
regular expression that accepts all strings and parses them
into the component parts.

I have absolutely no problem with writing a proposed standard
for parsing references, particularly if browser developers are
willing to adhere to one.  However, it is not a redefinition of
URLs, nor does it make sense for error-correcting transformations
(like pct-encoding embedded spaces) to be "the standard" for
parsing when there are plenty of applications that string
parse references for the sake of generating invalid test cases
(e.g., the example attributed to curl).

It is not non-interoperable behavior to parse input data
differently depending on the context in which it is entered.
What matters is that the context be properly documented to
indicate what pre/post-processing is applied, just as we
expect a browser's combined search/location dialog bars to
be documented as not merely URL-entry forms (or be banned
due to the privacy leakage of incremental search results).

....Roy

Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive< at >w3.org from September 2012)

Ian Hickson — 2012-10-24T17:02:16

Well I definitely don't think we should constrain a spec editor to being 
forced to use text he didn't even write, that seems like a very poor way 
to write a spec. Especially given that here the text is already spread 
across two specs (URI and IRI).

I think it makes sense to be conservative and say that URL synatx 
conformance requirements should probably not change from what the IRI spec 
says today unless there's a really compelling reason, though.



Well unless there's a very good reason (e.g. following the current specs 
involves a security vulnerability or something like that) then I'd think 
that was a reasonably strong technical requirement, sure. But that's 
independent of how the spec is written. It's trivial to write a spec that 
uses existing text while making all existing implementations 
non-conforming, for example (just add a line that says "implementations 
MUST NOT do what the following section says" or something...).

Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive< at >w3.org from September 2012)

Carsten Bormann — 2012-10-24T15:53:07


Hey, call them EARLs.  Error-tolerant web-Address Repairing Labels or whatever.
(Just not URLs, that term is already taken in the Web.)

Grüße, Carsten

Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24(public-whatwg-archive< at >w3.org from September 2012)

John C Klensin — 2012-10-24T11:38:41


--On Wednesday, October 24, 2012 11:39 +0100 Brian E Carpenter
<brian.e.carpenter< at >gmail.com> wrote:


Very useful perspective, IMO.

Seen that way, IRIs might then be considered a different flavor
of UIS.  Less heuristic than some, but not a flavor of URI.

best,
   john

Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive< at >w3.org from September 2012)

Jan Algermissen — 2012-10-24T11:04:25

On Oct 24, 2012, at 1:47 AM, Ian Hickson <ian< at >hixie.ch> wrote:


I ideally mean the actual text, but it might be that there is some overlap in the construction algorithms - I am not expert enough there to judge that.

The point really was to make it very clear that *additional* stuff is going to be said and that existing implementations that follow the URI spec strictly remain conforming.

Jan

Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive< at >w3.org from September 2012)

Anne van Kesteren — 2012-10-24T08:14:25

On Wed, Oct 24, 2012 at 8:41 AM, Manger, James H
<James.H.Manger< at >team.telstra.com> wrote:

Thanks for pointing that out. I renamed it to "fatal error flag" and
added an issue about the ability to halt on the first (non-fatal)
error. Ian is right that it's not defined yet because conformance is
not defined. And yes, as you say I've yet to figure out if branches in
the parser section is easy enough to do. If it is I think it's
worthwhile because it makes implementing a conformance checker (or
strict parser) much more straightforward.

RE: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive< at >w3.org from September 2012)

Manger, James H — 2012-10-24T06:41:16


That is good to hear. There is no hint about this in the current text/outline. There is an "invalid" flag in the current text -- but that is for strings that are so broken no error handling can resurrect a URL. There is no mention of a separate "conforming" flag, even if the rules for when to set it are yet to be fixed (though it should have been easy to say conforming=conforming-as-per-rfc3987/3987 if that was the intention).

Assuming this is Anne's intention, then 1 spec for URI/IRI/error-handling would be helpful. I'm not sure that parsing rules with conforming/non-conforming branches would be pretty, but perhaps this isn't necessary if what a conforming URL is is clear from other parts of the spec.

--
James Manger

RE: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive< at >w3.org from September 2012)

Ian Hickson — 2012-10-24T05:05:44

Well first, the whole point of discussions like this is to work out what 
the specs _should_ say; if the specs were perfect then there wouldn't be 
any need for discussion.

But second, I believe it's already Anne's intention to add to the parsing 
algorithm the ability to abort whenever the URL isn't conforming, he just 
hasn't done that yet because he hasn't specced what's conforming in the 
first place.


On Tue, 23 Oct 2012, David Sheets wrote:

I don't understand what your four algorithms are supposed to be.

There's just one algorithm as far as I can tell -- it takes as input an 
arbitrary string and a base URL object, and returns a normalised absolute 
URL object, where a "URL object" is a conceptual construct consisting of 
the components scheme, userinfo, host, port, path, query, and 
fragment, which can be serialised together into a string form.

(I guess you could count the serialiser as a second algorithm, in which 
case there's two.)



No, Anne hasn't finished defining conformance yet. (He just started 
today.)

You may be getting confused by the "invalid flag", which doesn't mean the 
input is non-conforming, but means that the input is uninterpretable.



No, it doesn't have to be. That's actually a more complicated way of 
looking at it than necessary, IMHO.



Personally I think this kind of open-ended approach is not a good way to 
write specs. Better is to put forward concrete use cases, technical data, 
etc, and let the spec editor take all that into account and turn it into a 
standard. Arguing about what precise alphabets are allowed and whether to 
spec something using prose or production rules is just bikeshedding.