Re: draft-abarth-url-01 uploaded

On Sun, Apr 24, 2011 at 5:37 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 24.04.2011 10:08, Adam Barth wrote:
>> On Sun, Apr 24, 2011 at 12:48 AM, Julian Reschke<julian.reschke@gmx.de>
>>  wrote:
>>> On 24.04.2011 00:31, Adam Barth wrote:
>>>>
>>>> I've uploaded a new version of draft-abarth-url:
>>>>
>>>> http://www.ietf.org/id/draft-abarth-url-01.txt
>>>>
>>>> This version has text in every (normative) section, but still has lots
>>>> of TODOs and there's still a lot of work to be done.  As always, you
>>>> can see the lastest up-to-the-commit version of the document here:
>>>>
>>>> https://github.com/abarth/url-spec/blob/master/drafts/url.xml
>>>>
>>>> My plan is to continue iterating on this document by resolving TODOs.
>>>
>>> I still don't understand the purpose -- see previous mails. To make
>>> progress
>>> on this we'll need a list of valid URIs you think need to be parsed
>>> differently from what RFC 3986 already says.
>>
>> I don't understand why that's a pre-requisite for this work.  We'll
>> generate that information as a byproduct of this work, of course, but
>> we don't need that information to make progress at this point.
>
> It depends on what "this work" means. If the WG is supposed to adopt this as
> a Working Draft, it better agrees first about what the purpose is.

This purpose of this document is to fulfill this requirement from the charter:

  * The IRI specification(s) must (continue to) be suitable
  for normative reference with Web and XML standards from W3C
  specifications. The group should coordinate with the W3C working
  groups on HTML5, XML Core, and Internationalization, as well
  as with IETF HTTPBIS WG to ensure acceptability.

The normative requirements of the document are something the working
group will need to reach consensus about.  You're more of an expert on
IETF process than I am, but I would be surprised if we would need to
agree about normative requirements of the document before adopting it
as a working group item.  That would seem to pre-judge the outcome.

>>> That being said: where does the spec define parsing relative references?
>>> (see<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.4.2>)
>>
>> The handling of relative references is in Section 4.  I was expecting
>> to need to define how to parse them, but that doesn't appear to be
>> necessary.
>
> It starts with
>
>   Given a string relative-url and a ParsedURL base-url, find the scheme
>   of relative-url.
>
> Finding the scheme aborts the algorithm when there is none, no?

Finding the scheme aborts the "finding the scheme" algorithm (hence
the separate section and the phrase "these steps") and reports that
the URL is invalid when there is no scheme.  The algorithm for
resolving a relative URL then continues down this branch "if
relative-url is an invalid URL...".

Adam

Received on Sunday, 24 April 2011 18:11:50 UTC