RE: I-D Action: draft-klensin-iri-sri-00.txt

Also on the real substance of the SRI vs IRI discussion...

Browsers today have an address bar.   That address bar today can often contain IRIs,
which are more readable than URIs.   The SRI isn't amenable to that UI paradigm which
was based on the URI-is-an-IRI principle.   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.   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.

-Dave

> -----Original Message-----
> From: Dave Thaler
> Sent: Monday, July 9, 2012 12:56 PM
> To: 'John C Klensin'; public-iri@w3.org
> Subject: RE: I-D Action: draft-klensin-iri-sri-00.txt
> 
> Thanks for writing this, it should generate a useful discussion.
> I have some editorial nits I'll leave to separate email, but here's some
> technical comments.
> 
> 1) Whereas the generic URI syntax defines an authority component, my
> understanding is that it's part of the scheme-specific hier-part so that a new
> scheme can define its "authority" component as something other than
>       authority   = [ userinfo "@" ] host [ ":" port ]
> If so, there should be some way of expressing an authority component
> that is something other than a "host" in the classic sense.   RFC 4395 section
> 2.2
> requires only that new schemes MUST adhere to Section 4.3 of RFC 3986
> which is
>       absolute-URI  = scheme ":" hier-part [ "?" query ] So you might want a
> hier-part element with authority and path being subsidiary elements.
> 
> 2) Regarding the "port" element.   One issue for both URIs and this (and IRIs)
> is that
> RFC 6335 recommends use of service names rather than static port numbers
> for new protocols.   So I'd expect new schemes to want to be capable of
> using
> them and not just port numbers.   RFC 3986 allows a new scheme to define
> its own
> hier-part, but we should really have a common way to express service
> names.
> Perhaps by:
>       authority   = [ userinfo "@" ] host [ ":" servicename ]
> RFC 6335 section 5.1 already requires service names to have a non-digit so
> there cannot be ambiguity.
> 
> 3) For the query element, if you're defining an XML syntax, it might be a good
> idea to define some typical way of expressing an unordered list of
> name/value pairs, since that's very common.
> 
> 4) Would be good to add an example showing what happens with "%", since I
> couldn't follow the text in section 4.
> 
> 5) Would be good to add an example showing how <> are encoded.  For
> example, if a user types in "</query>" into some app, which then wants to
> put the input string into the query component, what would the resulting XML
> look like?
> 
> -Dave
> 
> 
> > -----Original Message-----
> > From: John C Klensin [mailto:john-ietf@jck.com]
> > Sent: Monday, July 9, 2012 1:43 AM
> > To: public-iri@w3.org
> > Subject: FWD: I-D Action: draft-klensin-iri-sri-00.txt
> >
> > Hi.
> >
> > As many of you know or have deduced from earlier notes, I've wondered
> > what we could do to make a localization-friendly i18n structure for a
> > URI overlap if we dropped the strict compatibility requirement (e.g.,
> > that every valid URI must also be a valid IRI).  If IRIs are protocol
> > elements, that strict compatibility should no longer be a obvious
> requirement.
> >
> > SM and I have hacked together a draft in the hope of starting an
> > exploration of that question.   It is not complete, probably
> > contains errors, and we made some design decisions fairly arbitrarily.
> > The intent should, however, be relatively clear and sufficient to
> > start a discussion about tradeoffs and alternatives.
> >
> > best,
> >     john
> >
> >
> > ---------- Forwarded Message ----------
> > Date: Monday, July 09, 2012 01:27 -0700
> > From: internet-drafts@ietf.org
> > To: i-d-announce@ietf.org
> > Subject: I-D Action: draft-klensin-iri-sri-00.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >
> > 	Title           : An XML-based Simple Resource Identifier
> > 	Author(s)       : John C Klensin
> >                           Subramanian Moonesamy
> > 	Filename        : draft-klensin-iri-sri-00.txt
> > 	Pages           : 10
> > 	Date            : 2012-07-09
> >
> > Abstract:
> >    While the URI specification has been widely deployed, it has
> > long    been recognized that many valid URIs, especially those
> > that contain    extensive information in the "tail" are
> > unsuitable for user    presentation, especially for
> > internationalized environments.  IRIs    have been proposed as a
> > solution for that problem but inherit (and    are constrained
> > by) the complex and sometimes method-dependent syntax    model
> > of URIs as well as positional and ordering assumptions that make them
> > more difficult to localize than is desirable.
> >
> >    This specification illustrates a way to define an "above URI"
> > model    for a localization-friendly simple reference identifier
> > (SRI) that    explicitly identifies fields and is more
> > appropriate than IRIs to    support localization.  The current
> > version is intended simply to    initiate a discussion.  In
> > particular, while it is written to use an    XML element syntax
> > model, variations using JSON or some other system    with
> > explicitly-labeled data fields might be as, or more, appropriate.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-klensin-iri-sri
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-klensin-iri-sri-00
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > ---------- End Forwarded Message ----------
> >
> >
> >
> >
> >

Received on Monday, 9 July 2012 20:03:45 UTC