Re: Browser bars, etc.

On 2012/07/10 16:16, John C Klensin wrote:

> --On Monday, July 09, 2012 20:03 +0000 Dave Thaler
> <dthaler@microsoft.com>  wrote:

>> Browsers today have an address bar.

>>    That address bar today
>> can often contain IRIs, which are more readable than URIs.
>
> I'll agree with "more readable" but note that there seems to be
> an industry trend to be toward more and more complex URIs which
> are usefully accessible only from favorites/bookmarks, imported
> references, and search mechanisms of some flavor.  Discussions
> in the IETF may lead to reinforcing that trend (e.g., proposals
> to incorporate hashes instead of user names and of signed URIs).
> If one assumes a URL that goes on for several lines, with most
> of the relevant tail components present, possibly embedding
> another URL, multiple query components, and so on, then
> readability is an unreasonable expectation whether the abstract
> text is ASCII or not.  Even if it is not, the marginal
> percentage readability improvement from IRIs is likely to be
> miniscule.

There is a trend to longer URIs/IRIs. But that doesn't mean that short 
URIs are no longer used. And while the readability improvements may be 
marginal in some cases, they are absolutely crucial in others. Say a 
student writes a report and uses some Web pages as references. The 
readability difference between
    http://ru.wikipedia.org/wiki/Интернет
and
 
http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82
for anybody who can read Russian or is otherwise familiar with the 
Cyrillic script, is just huge.


> Even the structure of the address bar doesn't help much.  If the
> number of characters in an IRI or URI considerably exceeds the
> width of the address bar, readability and usability suffer: I
> have yet to see a browser that handles over-long URI strings in
> the address bar (such as by scrolling) really well.   IRIs might
> help by virtue of being shorter, but the window in which that is
> of large benefit to readability is not huge.

So IRIs help because they show the characters rather than %-encoding, 
AND because they make things shorter. Good point.


>> The SRI isn't amenable to that UI paradigm which was based on
>> the URI-is-an-IRI principle.
>
> If one preserves the [every] URI-is-a-[valid-]IRI principle, a
> number of convenient things happen.  Some inconvenient things
> happen too, a few of which SM and I tried to identify in the
> document.  But one of the reasons this I-D or something very
> like it wasn't written a half-dozen years ago was that there
> seemed to be general agreement that URI-is-an-IRI made sense.
> In that context, IRIs were no worse for localization than IDNs:
> perhaps, if one had a good "above DNS" layer that would do the
> kinds of language-based matching that end users had been
> encouraged to expect, IDNs would be almost useless because that
> layer could translate directly to strings with which the user
> would not need to deal, but, especially with the dual
> relationship between A-labels and U-labels introduced in
> IDNA2008, they would not be harmful.
>
> But, in that regard, IRIs ran into something of the same problem
> that IDNA2003 ran into: if one could not reverse the ISI->  URI
> transformation and reliably get back the same IRI, then there
> are uncomfortable side effects (including on the user's ability
> to interpret the address bar regardless of how readable it is).
> There were other issues as well, and the WG (or at least an
> active fraction of it) concluded that IRIs should be independent
> protocol elements, similar to URIs but independent of them and
> perhaps most suitable for new protocols.

You seem to be confused. There is absolutely no change from "every URI 
is an IRI". At no point the WG concluded that IRIs should be totally 
independent of URIs. Of course IRIs, like IDNs, are easier to introduce 
into new protocols. For existing protocols, whether introducing IRIs 
where up to now only URIs have been in use makes sense depends a lot on 
existing implementations,.... Again, that's the same as for IDNs.


> Depending on how far that goes --and I really don't have a clear
> picture of how far it is going-- URI-is-an-IRI works for RFC
> 3897 IRIs but may not apply for draft-ietf-iri-3897bis IRIs.

It applies. If there's a place in the draft where it doesn't, please 
tell us and we'll make sure we'll fix it.


>>   In this proposal to get rid of
>> that principle, it would be worth discussing UI paradigm
>> principles, since the XML representation  can't be easily
>> rendered in such a box.
>
> Yes, but note that draft-ietf-iri-3897bis proposes to get rid of
> that principle too.  Not as dramatically of course -- under
> draft-ietf-iri-3897bis, many URIs will still be IRIs

All URIs are still IRIs. If you know about an URI that isn't an IRI 
anymore, please just put it in your next mail, and we'll have a look at 
it and fix it.


-- but,
> unless the WG reverses itself, the discussion is not about
> whether to get rid of the principle or not but about what to
> replace the discarded principle with.

The WG doesn't have to reverse itself.

>>    That means without IRIs, it seems
>> one would either need a radically different paradigm, or one
>> would need to always display the less-readable URI form.   I
>> don't think always rendering the URI form would be any better
>> for usability, so to me this proposal is tightly tied to the
>> discussion of alternate rendering paradigms.
>
> Agreed.  But, again, that is "without IRIs that preserve the
> URIs-are-always-IRIs principle"

Which we don't have.

> and "with many longer and more
> URIs even without i18n",

Please note that the URI/IRI ecosystem is quite well organized in that 
URIs/IRIs that need to be short get made short (the extreme example is 
URI/IRI shorteners so that they fit into Twitter messages), and 
URIs/IRIs that benefit from using words rather than just arbitrary 
character combinations use them. On the other hand, where it's less 
important, URIs (and IRIs) may become overly long and cryptic. In many 
ways, the principles of "natural" selection apply. If you don't make an 
URI/IRI short where that helps, then the URI/IRI (actually, the resource 
behind it) just isn't used.


Regards,    Martin.

Received on Wednesday, 11 July 2012 11:31:44 UTC