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

[Ted Hardie <[e-mail]>]

Thank you for your comments and the update; I have no further
recommendations.

regards,

Ted Hardie

On Wed, Oct 3, 2018 at 7:23 AM Benjamin PHISTER <[e-mail]>
wrote:

> Hi Dave and Ted,
>
> Thank you for your thoughts and suggestions.
>
> 1. The encoding method proposed by Ted (and supported by Dave) for
> defining URIs is indeed much simpler.
>
> We will modify the introduction of Section 4. and the method described in
> 4.1 accordingly, so that the URI definition doesn't depend on IRIs.
>
> Concerning the use IRIs, we will modify the text to indicate that it
> concerns only end-user applications for which the use of IRIs is allowed.
>
> 2. About the behavior of Frogans Player
>
> Ted pointed out that in different parts of the draft, the text is not
> clear about whether it covers further implementations of Frogans Player or
> only the current implementation.
>
> The fact that these parts were written using the present tense (e.g.
> "Frogans Player always displays the real Frogans address") left open doubts
> about future implementations.
>
> We will modify these parts so as to indicate that they apply to all
> implementations.
>
> 3. Concerning the use of an access page (
> https://www.frogans.org/en/resources/ifap/access.html) to refer to
> version 1.1 of  the IFAP specification.
>
> Given that the access page lists all versions of the IFAP specification,
> Ted suggested we provide a direct link to version 1.1 of the IFAP
> specification (
> https://www.frogans.org/en/resources/ifap/ifap11-adopted.spec.txt).
>
> We prefer to keep the reference to the access page for the following
> reasons:
>
> a) The URL of the access page is a permanent URL (The OP3FT will not
> modify this URL in the future)
>
> b) The permanent URL is mentioned in the IFAP specification itself.
>
> c) This access page contains links to 11 data files referenced by the IFAP
> specification (for example
> https://www.frogans.org/en/resources/ifap/ifap11-adopted.spec.ilt01-character-set.txt
> )
>
> d) Version 1.1 of the IFAP specification is mentioned in the reference
> provided in the draft:
>
>    [IFAP]     OP3FT, "International Frogans Address Pattern",
>               *Version 1.1*, ISBN 978-2-37313-000-3, November 2014,
>               <https://www.frogans.org/en/resources/ifap/access.html>
> <https://www.frogans.org/en/resources/ifap/access.html>.
>
>
> We have just submitted a new draft
> "draft-op3ft-leaptofrogans-uri-scheme-03" reflecting changes discussed in
> points 1 and 2 above. See
> https://datatracker.ietf.org/doc/draft-op3ft-leaptofrogans-uri-scheme/
>
> Regards,
>
> Benjamin and Alexis
>
>
> ------------------------------
> *From:* Dave Thaler <[e-mail]> <[e-mail]>
> *Subject:* [Uri-review] URI review request for 'leaptofrogans' scheme
> *Date:* Friday, Sep 14, 2018 8:24 PM CEST
> *To:* Ted Hardie <[e-mail]> <[e-mail]>, Peter
> Saint-Andre <[e-mail]> <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> <[e-mail]>, [e-mail] <[e-mail]>
> <[e-mail]>, Jean-Emmanuel RODRIGUEZ
> <[e-mail]> <[e-mail]>,
> Benjamin PHISTER <[e-mail]> <[e-mail]>
>
> +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 <[e-mail]>
> <[e-mail]> *On Behalf Of *Ted Hardie
> *Sent:* Friday, September 14, 2018 10:23 AM
> *To:* Peter Saint-Andre <[e-mail]> <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; Jean-Emmanuel
> RODRIGUEZ <[e-mail]>
> <[e-mail]>; Benjamin PHISTER
> <[e-mail]> <[e-mail]>
> *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:
>
>
>
>    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 <[e-mail]>
> 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>
>
> 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:[e-mail]
>
>    Change controller: OP3FT mailto:[e-mail]
>
>    References: RFC xxxx.
>
> ###
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> 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>
>
>
>
>
> --
> Benjamin Phister
> Head of Technical [e-mail]
>
> OP3FT
> 6 square Mozart
> 75016 Paris - France
> Tel: [phone]https://www.op3ft.org/
> frogans*op3ft
>
>