W3C home > Mailing lists > Public > public-webid@w3.org > November 2012

Re: Should specifications take sides in the httpRange-14 debate?

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Wed, 21 Nov 2012 16:49:48 +0100
Message-ID: <CAKaEYhLbigEG1hVHLUHDUZ3d5ayO59rFJGykVCEfEGaJoeV1tA@mail.gmail.com>
To: Henry Story <henry.story@bblfish.net>
Cc: Kingsley Idehen <kidehen@openlinksw.com>, public-webid@w3.org
On 21 November 2012 15:11, Henry Story <henry.story@bblfish.net> wrote:

>
> On 21 Nov 2012, at 15:03, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>
>  On 11/21/12 8:10 AM, Henry Story wrote:
>
>
>>  I think there Larry makes a good point with regard to URI/URLs. Now that
>> we have
>> agreed to restrict to http/https URI's we should use the URI term, as
>> that deals
>> with internationalisation.
>>
>
>  you mean IRI right? That was also part of Antoine's feedback to switch
> from URI to IRI.
>
>
>  We go for what we need. Larry wrote:
>
>  "The design proposed is one where there is a WebID protocol element
> whose value resembles a URL (not a URI? Surely you are not planning on
> requiring the non-English world to use ASCII WebIDs?) "
>
>  It seems that URIs are enough for that problem.
>
>
> You are being selective again. You use IRI once internationalization is a
> factor, end of story.
>
>
> Larry Masinter was being selective. Why was he? I am sure he knows of IRIs
> too.
>
> If you want IRIs please open an issue for it.
>

It may be possible that larry made a typo :)


>
> Henry
>
>
> --
>
> Regards,
>
> Kingsley Idehen	
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>
> Social Web Architect
> http://bblfish.net/
>
>
Received on Wednesday, 21 November 2012 15:50:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:46 UTC