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 19:56:18 UTC