SRI technical issues (was: RE: I-D Action: draft-klensin-iri-sri-00.txt)

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

> 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.

Thanks.

General observation: While I find these suggestions very helpful
(and have responded below), they are important only if the WG
wants to pursue the idea or, in some cases, if details are
needed as part of the proof of concept.    Advice from
participants in the WG as to whether they would like to see a
new draft before the cutoff and/or early in IETF 84 (since IRI
isn't scheduled to meet, if at all, until late Thursday
afternoon) would be appreciated.

> 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.

Yes, almost certainly.  In our relative haste to get the draft
out, we didn't have time to do a really careful review of RFC
3986 for cases like this.   If the WG wishes to pursue the
approach, that will clearly have to be done.  In the interim,
I've noted this in the working copy.

> 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.

Ack.  Noted in working draft.  Another question is whether
things like servicenames/ports should be expressed as separate
elements or as parameters to existing ones, e.g., whether, for
the domain case, the above would be better expressed as 

   <host><domain>xxxx</domain></host>
<servicename>service-or-port</servicename>

or as, e.g.,
  <host servicename="service-or-port">
<domain>xxx</domain></host>

That should be left to WG preference and especially people who
have a better-developed sense of XML aesthetics than I do but,
if we are going to go forward with this general idea, it should
be addressed.

> 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.

Yes.  Or providing a canonical ordering, however artificial.
Making comparison each is A Good Thing.   Advice from XML
experts would be appreciated on this.  In the interim, I've put
a placeholder note in the working draft.

> 4) Would be good to add an example showing what happens with
> "%", since I couldn't follow the text in section 4.

I've have another look at the text, but the short answer is that
nothing happens to "%".  It is just a normal character.  My hope
is that the only escape arrangements would be those required by
XML and that we can get rid of most of those.   If we need a
character escape (and I hope we don't), it should follow the
\u(NNNN) convention of RFC 5137 rather than encoding octets of
UTF-8.
 
> 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?

Yes.  And that is the case where I'm not sure how to avoid
"&lt;", but requiring the use of CDATA might be the better plan.
Advice from XML experts would be appreciated here.

best,
   john

Received on Tuesday, 10 July 2012 08:01:29 UTC