Subject: [Uri-review] URI review request for 'leaptofrogans' scheme

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 14 Sep 2018 09:52:47 -0600

This message constitutes a request for review of the 'leaptofrogans' URI
scheme, specified here:

https://datatracker.ietf.org/doc/draft-op3ft-leaptofrogans-uri-scheme/

Although the completed registration template follows, reading the I-D is
advised. I am the document shepherd and have cc'd the authors.

###

6.  IANA Considerations

   [RFC Editor: Please replace 'xxxx' with assigned RFC number before
   publication]

   In accordance with the guidelines and registration procedures for new
   URI schemes [RFC7595], this section provides the information needed
   to register the 'leaptofrogans' URI scheme.

   Scheme name: 'leaptofrogans'

   Status: permanent

   URI Scheme Syntax: See Section 4 of RFC xxxx.

   URI Scheme semantics: See Section 2 of RFC xxxx.

   Encoding Considerations: See Section 4 of RFC xxxx.

   Applications/protocols that use this scheme name: Frogans Player as
   well as any end-user application (such as a Web browser or an E-mail
   client) wishing to launch Frogans Player on a given Frogans site.

   Interoperability Considerations: There are no known interoperability
   concerns related to use of the 'leaptofrogans' URI scheme.

   Security Considerations: See Section 7 of RFC xxxx.

   Contact: Alexis Tamas mailto:[email-masked]

   Change controller: OP3FT mailto:[email-masked]

   References: RFC xxxx.

###

---

From: Ted Hardie <[email-masked]>
Date: Fri, 14 Sep 2018 10:22:57 -0700

Howdy,

draft-op3ft-leaptofrogans-uri-scheme references the IFAP spec but the
pointer given is to an access page; it would likely be clearer to point to
a specific version, e.g.
https://www.frogans.org/en/resources/ifap/ifap10-adopted.spec.txt .

I personally found the discussion of the relationship of leaptofrogans to
IRIs somewhat confusing and under-specified.  From what I have worked out,
the Frograns networks and Frogans sites are both forbidden by IFAP from
using the percent symbol within their names.  This means that any
leaptofrograns URIs will not need to deal with percent-encoding any
existing percent signs.  The document goes on to say:

   This is because Frogans Player interprets both URIs
   and IRIs based on the 'leaptofrogans' URI scheme.  If the U+0025
   PERCENT SIGN character is found in the string, then the string is
   interpreted as a URI, otherwise it is interpreted as an IRI.

While it may be useful to know what the Frogans Player currently does, the
specification really has to say what further implementation should do, and
this isn't really clear.  Similarly, the Security considerations section
lists mitigations that are specific to a particular piece of software,
rather than more generally.  Up-leveling this so it is useful to other
implementations would be good.

I also must confess to a general concern about the use of IRIs.  At the
time the IRI documents were written, they were conceived of as a
presentation form useful for interacting with users, but the underlying
assumption was that protocol elements would always be URIs.  See this from
Section 3 fo RFC 3987:

   However, when the resource
   identifier is used for resource retrieval, it is in many cases
   necessary to determine the associated URI, because currently most
   retrieval mechanisms are only defined for URIs.  In this case, IRIs
   can serve as presentation elements for URI protocol elements.

This document appears to be defining a scheme for use with a resource
retrieval system, but it is doing so with the IRIs as the primary
identifier.  It's outside the scope of this discussion to review the
implications of that for IFAP, but I think it is fair to note that IRIs
have not been a resounding success, and that even if the IRI usage were
very completely specified here the chances that libraries outside the
Frograns ecosystem would support it seems small.  I infer that in part
because of the special casing in IFAP (e.g. the use of an IDNA-based
repertoire but with the restoration of the asterisk to PVALID within
Frogans strings) , but mostly on the general state of IRI processing.

I think this could be substantially simpler, by defining these as URLs
where any Frograns Network or Frogans Site which uses characters outside
the US-ASCII range encodes them with percent encoding when constructing a
URL.
This might also simplify the equivalence matching algorithm, but that
depends a bit on your needs there.

regards,

Ted Hardie

On Fri, Sep 14, 2018 at 8:52 AM, Peter Saint-Andre <[email-masked]>
wrote:

> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: Dave Thaler <[email-masked]>
Date: Fri, 14 Sep 2018 18:24:31 +0000

+1 to this recommendation from Ted:

Ø  I think this could be substantially simpler, by defining these as URLs where any Frograns

Ø  Network or Frogans Site which uses characters outside the US-ASCII range encodes them

Ø  with percent encoding when constructing a URL.   This might also simplify the equivalence

Ø  matching algorithm, but that depends a bit on your needs there.

One issue with IRIs is that if they are used directly in web pages, such that the client gets to do the IRI-to-URI
conversion, you will get different results since the client might follow RFC 3987 (e.g., Windows UWP apps do)
but browsers do not, they tend to follow a conversion process closer to the iri-bis drafts that never became
RFCs (e.g., that use the charset of the containing page, rather than UTF-8).  As such, you do not get reliable
interoperable behavior.

If they always appear in web pages as URIs (not IRIs) such that the author does the conversion, then you can
get interoperable behavior.  Hence the recommendation.

Dave

From: Uri-review <[email-masked]> On Behalf Of Ted Hardie
Sent: Friday, September 14, 2018 10:23 AM
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked]; [email-masked]; Jean-Emmanuel RODRIGUEZ <[email-masked]>; Benjamin PHISTER <[email-masked]>
Subject: Re: [Uri-review] URI review request for 'leaptofrogans' scheme

Howdy,

draft-op3ft-leaptofrogans-uri-scheme references the IFAP spec but the pointer given is to an access page; it would likely be clearer to point to a specific version, e.g. https://www.frogans.org/en/resources/ifap/ifap10-adopted.spec.txt<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.frogans.org%2Fen%2Fresources%2Fifap%2Fifap10-adopted.spec.txt&data=02%7C01%7Cdthaler%40microsoft.com%7Cf2dd94c00ff641f78d7c08d61a66edcb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636725426718904009&sdata=ekn%2BaOZOnxg98DsRAAWbezfXGEmkG6uL4DOfKnWzC3A%3D&reserved=0> .

I personally found the discussion of the relationship of leaptofrogans to IRIs somewhat confusing and under-specified.  From what I have worked out, the Frograns networks and Frogans sites are both forbidden by IFAP from using the percent symbol within their names.  This means that any leaptofrograns URIs will not need to deal with percent-encoding any existing percent signs.  The document goes on to say:

   interpreted as a URI, otherwise it is interpreted as an IRI.
While it may be useful to know what the Frogans Player currently does, the specification really has to say what further implementation should do, and this isn't really clear.  Similarly, the Security considerations section lists mitigations that are specific to a particular piece of software, rather than more generally.  Up-leveling this so it is useful to other implementations would be good.

I also must confess to a general concern about the use of IRIs.  At the time the IRI documents were written, they were conceived of as a presentation form useful for interacting with users, but the underlying assumption was that protocol elements would always be URIs.  See this from Section 3 fo RFC 3987:

   can serve as presentation elements for URI protocol elements.
This document appears to be defining a scheme for use with a resource retrieval system, but it is doing so with the IRIs as the primary identifier.  It's outside the scope of this discussion to review the implications of that for IFAP, but I think it is fair to note that IRIs have not been a resounding success, and that even if the IRI usage were very completely specified here the chances that libraries outside the Frograns ecosystem would support it seems small.  I infer that in part because of the special casing in IFAP (e.g. the use of an IDNA-based repertoire but with the restoration of the asterisk to PVALID within Frogans strings) , but mostly on the general state of IRI processing.

I think this could be substantially simpler, by defining these as URLs where any Frograns Network or Frogans Site which uses characters outside the US-ASCII range encodes them with percent encoding when constructing a URL.
This might also simplify the equivalence matching algorithm, but that depends a bit on your needs there.

regards,

Ted Hardie

On Fri, Sep 14, 2018 at 8:52 AM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>> wrote:
This message constitutes a request for review of the 'leaptofrogans' URI
scheme, specified here:

https://datatracker.ietf.org/doc/draft-op3ft-leaptofrogans-uri-scheme/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-op3ft-leaptofrogans-uri-scheme%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Cf2dd94c00ff641f78d7c08d61a66edcb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636725426718904009&sdata=tpbuF%2FkvIUoH84SO%2BfAYIZM8o4q3Sum%2FwhgbizbKe2Q%3D&reserved=0>

###

6.  IANA Considerations

   Status: permanent

   Contact: Alexis Tamas mailto:[email-masked]<mailto:[email-masked]>

   Change controller: OP3FT mailto:[email-masked]<mailto:[email-masked]>

   References: RFC xxxx.

###

_______________________________________________
Uri-review mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/uri-review<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Furi-review&data=02%7C01%7Cdthaler%40microsoft.com%7Cf2dd94c00ff641f78d7c08d61a66edcb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636725426718904009&sdata=XmdjS14AgU3n4T4b1ZeC8wYDS2SFBAvKt1un3SEbG7A%3D&reserved=0>