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

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.

s

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 ap

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 re

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 jus