- From: Mykyta Yevstifeyev <evnikita2@gmail.com>
- Date: Sun, 14 Aug 2011 12:38:21 +0300
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: public-iri@w3.org
Here comes the list of issues in the tracker for particular comments: 01.08.2011 10:14, Mykyta Yevstifeyev wrote: > Hello, > > I understand there is no support for my proposition, so I don't insist > any more. As I've already mentioned, I'm not opposed to its > publication, and I'd like to comment it, then. > > Section 1: > >> [RFC3987] introduced IRIs by defining a mapping >> between URIs and IRIs; [RFC3987bis] updates that definition, >> allowing >> an IRI to be interpreted directly without translating into a URI. > > I actually don't see RFC 3987 requiring an IRI to be translated to URI > under any circumstances. Current implementations of IRIs, under RFC > 3987, work perfectly without mapping any IRI to URI. So I think this > statement should be changed to: > >> [RFC3987] introduced IRIs by extending the characetr range allowed >> for URIs from ASCII to Universal Characetr Set (UCS); [RFC3987bis] >> updates that definition to suit IRIs' current usage. > > Ibid: > >> reserving the >> term "URN" explicitly for those URIs/IRIs using the "urn" scheme >> name >> ([RFC2141]). > > RFC 2141 doesn't allow 'urn' IRIs, not they exist at all. I propose > the following correction: OLD: "URIs/IRIs", NEW: "URIs". These two are http://trac.tools.ietf.org/wg/iri/trac/ticket/69. > > Section 3.1: > >> New URI/IRI schemes SHOULD >> have clear utility to the broad Internet community, beyond that > > I don't understand use of "SHOULD" here. From RFC 2119: > >> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there >> may exist valid reasons in particular circumstances to ignore a >> particular item, but the full implications must be understood and >> carefully weighed before choosing a different course. > > What are such "valid reasons"? I suppose you should use here "MUST" > or "must", but not "SHOULD". This is a requirement, not a > recommendation. This is http://trac.tools.ietf.org/wg/iri/trac/ticket/70. > > Section 3.2: > >> <absolute-URI> grammar described in [RFC3987bis]. > > Maybe <absolute-IRI>? See http://trac.tools.ietf.org/wg/iri/trac/ticket/71. > Ibid: > >> Schemes that do not >> contain a conformant hierarchical structure in their<scheme- >> specific-part> SHOULD NOT use double slashes following the >> "<scheme>:" string. > > I don't recall the <scheme-specific-part> production either in RFC > 3986, RFC 3987 or RFC 3987bis. Maybe you meant <hier-part>/<ihier-part>? http://trac.tools.ietf.org/wg/iri/trac/ticket/72 > > Section 3.8: > >> Organizations that desire a private name space for URI scheme names >> are encouraged to use a prefix based on their domain name, expressed >> in reverse order. For example, a URI scheme name of >> com-example-info >> might be registered by the vendor that owns the example.com domain >> name. > > Do we actually need this? I have never even heard of any attempts to > register such scheme. http://trac.tools.ietf.org/wg/iri/trac/ticket/73 > > Section 4: > >> (In the >> unfortunate case that there are multiple, different uses of the >> same scheme name, the IESG may approve a request to modify an >> existing entry to note the separate use.) > > I don't really think this may be necessary (probably for the sake of > robustness, but...). Maybe I'm wrong, but I don't know whether there > are some schemes which have different usage. http://trac.tools.ietf.org/wg/iri/trac/ticket/74 > > Section 5: > >> Any scheme that is no longer in common use MAY be designated as >> historical > > I suppose "SHOULD" is more appropriate here. But RFC 2119 might also > be inappropriate to be used here as well, and "should" may be OK as well. http://trac.tools.ietf.org/wg/iri/trac/ticket/75 > > Section 6.2, bullet 2: >> The >> template may also be submitted in some other form (as part of >> another document or as a stand-alone document), but the contents >> will be treated as an "IETF Contribution" under the >> guidelines of >> [RFC3978]. > > RFC 3978 was obsoleted by RFC 5378. http://trac.tools.ietf.org/wg/iri/trac/ticket/76 > > Section 6.3: > >> In cases where the original >> definition of the scheme is contained in an IESG-approved document, >> update of the specification also requires IESG approval. > > I suppose you should have clearly mentioned that the Standards Track > document MUST have IESG as the change controller http://trac.tools.ietf.org/wg/iri/trac/ticket/77 > > Section 6.4: > >> Author/Change controller: >> Person (including contact information) authorized to change this, >> if a provisional registration. > > I's like you dropped "if a provisional registration", as the > registration may also be changed if it is a permanent one. http://trac.tools.ietf.org/wg/iri/trac/ticket/79 > > Section 11.1. Why do you reference RFC 3987 normatively? At the time > the document is published RFC 3987bis will also have been published. > I don't see the reason for making RFC 2141 normative reference as well. Already covered in http://trac.tools.ietf.org/wg/iri/trac/ticket/56; now closed, but the issue with 3987/3987bis isn't. > > Some general comments. Where you point to specific URI schemes, it > may be useful to refer to corresponding documents. I recall there are > 'mid', 'ftp' and 'telnet' schemes mentioned there. http://trac.tools.ietf.org/wg/iri/trac/ticket/80 > > The document should be clear regarding what the "scheme" means. I > mean (sorry for pun) that the "scheme" may refer to the URI/IRI's > part; it may also refer to the "model" of a particular URI, eg. its > specification - syntax and semantics. http://trac.tools.ietf.org/wg/iri/trac/ticket/81 > > The proposal to Section 3.8, "Scheme Name Considerations". I think > the document should prescribe that the ":" character should not occur > in URI scheme name, as eg. in RFC 6196. This is incorrect; the > justification may be found in Erratum report #2756 > (http://www.rfc-editor.org/errata_search.php?eid=2756). http://trac.tools.ietf.org/wg/iri/trac/ticket/82 > > Regarding Section 6.4, registration template. Won't this be useful to > ad a new field "registration information" with the contents as for URN > namespaces (http://tools.ietf.org/html/rfc3406#appendix-A)? http://trac.tools.ietf.org/wg/iri/trac/ticket/83 > > The document should be clear that its recommendations don't have > retroactivity; those RI schemes which weren't suited to IRIs, as being > registered before it, shouldn't be used with IRIs. http://trac.tools.ietf.org/wg/iri/trac/ticket/84 Mykyta Yevstifeyev > > I hope my comments were useful. > > Mykyta Yevstifeyev > > 31.07.2011 9:01, Julian Reschke wrote: >> On 2011-07-31 06:27, Mykyta Yevstifeyev wrote: >>> Hello, >>> >>> I am not opposed to publication of the document, but I still think the >>> approach I proposed >>> (http://lists.w3.org/Archives/Public/public-iri/2011Jun/0097.html) is >>> better. Don't you think so? >>> ... >> >> I don't think so. It's the way how specs should be revised. >> > >
Received on Sunday, 14 August 2011 09:38:13 UTC