Re: Change definition of URL to normatively reference IRI specification using a well-defined interface

Hello Maciej, Ian, others,

First, I have added public-iri@w3.org, the mailing list of the IETF IRI 
WG, to the cc, because I think it's important that the IRI WG 
understands the requirements from the (W3C) HTML WG's side.

On 2010/04/08 17:46, Maciej Stachowiak wrote:
>
> Hi Larry,
>
> Thanks for chiming in.
>
> On Apr 8, 2010, at 1:32 AM, Larry Masinter wrote:
>
>> There has been some discussion in the HTML working group over how to
>> get changes into the IRI spec in IETF, specifically with requirements
>> for a better interface for some processing.
>>
>> Ø “If we can get agreement to provide an interface roughly similar to
>> what Ian proposed…”
>>
>> Honestly, I thought the IRIBIS document actually had what is being
>> asked for here. So I’d like someone else to look & see if they can
>> figure out what’s not there that needs to be there, or make specific
>> proposals.
>
> I looked at section 7.2 in what I believe is the latest Internet-Draft:
> <http://tools.ietf.org/html/draft-duerst-iri-bis-07>.

In terms of actual content, this is mostly irrelevant (because there 
haven't been much content-wise changes), but the latest Internet-Draft 
is http://tools.ietf.org/html/draft-ietf-iri-3987bis-00.

The relevant "REPLACED-BY" information is actually missing at 
http://tools.ietf.org/wg/iri/; I have asked that it be added. An 
additional pointer should then appear at the top of 
http://tools.ietf.org/html/draft-duerst-iri-bis-07. Thanks for helping 
us detect this issue.

> That's the section
> that defines lenient "Web Address" style processing.
>
> I see a preprocessing algorithm defined, but I do not see definitions of
> "parse" or "resolve" algorithms with the inputs and outputs Ian asked
> for. In fact, the words "parse" and "resolve" do not seem to appear in
> that section. I think the proposal at the start of this thread is asking
> for a single term, algorithm, or subsection that has the requested
> inputs and outputs in each case, and performs the intended task (modulo
> bugs).

Larry did most (if not all) editing on this issue, but as far as I 
understand, the plan was to cover the parsing part (which is potentially 
useful for any spec using IRIs, even if it has way less baggage than 
HTML) in Section 3.2 (with the help of the syntax in Section 2). Section 
7.2 would then only cover those aspects more specific to legacy 
implementations (such as HTML), stuff that we would hope new uses of 
IRIs wouldn't need to adopt.

However, it is clear that the HTML spec needs very precise entry points 
into the IRI spec, and there we clearly have to do some more work.

Regards,    Martin.

>> > I'd really really like to hear from Larry or one of the other IRIbis
>> editors whether this basic approach is acceptable
>>
>> As far as process issues in IRIBIS, please check with the chairs, who
>> are currently Ted Hardie and Marc Blanchet for authoritative answers.
>>
>> My current belief is that the IETF IRI WG will IETF tracker at
>> http://tools.ietf.org/wg/iri/trac/report/1, and that the chairs will
>> use the tracker to drive discussion and resolution.
>
> That makes sense as an approach to tracking proposed IRIbis changes. If
> thethe IRIbis chairs have any guidance that would be welcome as well.
>
>
> Regards,
> Maciej
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

Received on Thursday, 8 April 2010 10:50:35 UTC