[iri] #69: Several issues in Introduction of 4395bis

[iri issue tracker]

#69: Several issues in Introduction of 4395bis


Comment (by ted.ietf@…):

Agree with the general issue, but I propose slightly different language to
resolve it: "reserving the term URN explicitly for the URIs using the
"urn" scheme name ([RFC2141]). This also reserves the string "urn" so
that no IRI scheme with that string may be registered."
--
-------------------------+------------------
Reporter: evnikita2@… | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: 4395bis | Version:
Severity: - | Resolution:
Keywords: |
-------------------------+------------------

Ticket URL: <http://trac.tools.ietf.org/wg/iri/trac/ticket/69#comment:1>
iri <http://tools.ietf.org/wg/iri/>

[Peter Saint-Andre]

Post by iri issue tracker
#69: Several issues in Introduction of 4395bis
Agree with the general issue, but I propose slightly different language to
resolve it: "reserving the term URN explicitly for the URIs using the
"urn" scheme name ([RFC2141]). This also reserves the string "urn" so
that no IRI scheme with that string may be registered."

That looks better.

Larry pointed out that we might just want to register 'urn' as a URI/IRI
scheme, but it appears that is already effectively done according to the
registry:

http://www.iana.org/assignments/uri-schemes.html

Scheme Description Reference
...
urn Uniform Resource Names (click for registry) [RFC2141]

Peter

[Peter Saint-Andre]

Post by Peter Saint-Andre

Post by iri issue tracker
#69: Several issues in Introduction of 4395bis
Agree with the general issue, but I propose slightly different language to
resolve it: "reserving the term URN explicitly for the URIs using the
"urn" scheme name ([RFC2141]). This also reserves the string "urn" so
that no IRI scheme with that string may be registered."

That looks better.

<hat type='individual'/>

Looking back at the open issues, I noticed the first half of issue #69,
posted by Mykyta Yevstifeyev:

###

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.

###

Strictly speaking, UCS is not a character range (or, more precisely, a
character repertoire) but a coded characer set (and UCE-2/UCS-4 are
encoding forms). Therefore I suggest that the following is more accurate
and more consistent with RFC 6365:

[RFC3987] introduced IRIs by expanding the character repertoire
allowed for URIs from ASCII to Unicode [UNICODE]; [RFC3987bis]
updates that definition to match the current usage of IRIs.

Peter

[Bjoern Hoehrmann]

Post by Peter Saint-Andre
Strictly speaking, UCS is not a character range (or, more precisely, a
character repertoire) but a coded characer set (and UCE-2/UCS-4 are
encoding forms). Therefore I suggest that the following is more accurate
[RFC3987] introduced IRIs by expanding the character repertoire
allowed for URIs from ASCII to Unicode [UNICODE]; [RFC3987bis]
updates that definition to match the current usage of IRIs.

I don't like starting a stence with a reference like that, rather spell
out "RFC 3987 [RFC3987]" if you can't move things around, and I do not
like "expanding the character repertoire allowed for" at all, the words
do not go together like that. Could this just say this updates RFC 3987
to reflect current usage?

[Peter Saint-Andre]

Post by Bjoern Hoehrmann

Post by Peter Saint-Andre
Strictly speaking, UCS is not a character range (or, more precisely, a
character repertoire) but a coded characer set (and UCE-2/UCS-4 are
encoding forms). Therefore I suggest that the following is more accurate
[RFC3987] introduced IRIs by expanding the character repertoire
allowed for URIs from ASCII to Unicode [UNICODE]; [RFC3987bis]
updates that definition to match the current usage of IRIs.

I don't like starting a stence with a reference like that, rather spell
out "RFC 3987 [RFC3987]" if you can't move things around, and I do not
like "expanding the character repertoire allowed for" at all, the words
do not go together like that. Could this just say this updates RFC 3987
to reflect current usage?

I'll leave the wordsmithing to the document editors, but the first
clause is about the introduction of RFC 3987 and the second clause is
about the migration from RFC 3987 to rfc3987bis.

Peter

[Ted Hardie]

   [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

I read this text as referring to the applicability section in RFC 3987
(Section 1.2), which does explicitly say "The compatibility is
provided by specifying a well-defined and deterministic mapping from
the IRI character sequence to the functionally equivalent URI
character sequence." This goes back to our long-running "Presentation
format/new protocol element type" discussion, in other words.

I'm not honestly sure that we need this history in the document at
all. "This document updates the definition of IRIs originally
provided in RFC 3987" seems to sidestep the whole thing.

Ted

[Peter Saint-Andre]

Post by Ted Hardie

Post by Peter Saint-Andre
[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

I read this text as referring to the applicability section in RFC 3987
(Section 1.2), which does explicitly say "The compatibility is
provided by specifying a well-defined and deterministic mapping from
the IRI character sequence to the functionally equivalent URI
character sequence." This goes back to our long-running "Presentation
format/new protocol element type" discussion, in other words.
I'm not honestly sure that we need this history in the document at
all. "This document updates the definition of IRIs originally
provided in RFC 3987" seems to sidestep the whole thing.

Works for me.

Peter

[Larry Masinter]

+1 me too.

Post by Ted Hardie
I'm not honestly sure that we need this history in the document at
all. "This document updates the definition of IRIs originally
provided in RFC 3987" seems to sidestep the whole thing.

Works for me.

[iri issue tracker]

#69: Several issues in Introduction of 4395bis

#choose ticket.new
#when True
From http://lists.w3.org/Archives/Public/public-iri/2011Aug/0002.html:
----

Post by Peter Saint-Andre
[RFC3987] introduced IRIs by defining a mapping
between URIs and IRIs; [RFC3987bis] updates that definition,

allowing

Post by Peter Saint-Andre
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

Post by Peter Saint-Andre
[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.
reserving the
term "URN" explicitly for those URIs/IRIs using the "urn" scheme

name

Post by Peter Saint-Andre
([RFC2141]).

RFC 2141 doesn't allow 'urn' IRIs, not they exist at all. I propose the
following correction: OLD: "URIs/IRIs", NEW: "URIs".
#end
#otherwise
#if changes_body
Changes (by stpeter@…):


#end
#if changes_descr
#if not changes_body and not change.comment and change.author
Description changed by stpeter@…:
#end

--
#end
#if change.comment

Comment(by stpeter@…):

As discussed on the list, the proposed solutions are:

OLD
[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.
NEW
This document updates the definition of IRIs originally provided in
[RFC 3987].

OLD
reserving the
term "URN" explicitly for those URIs/IRIs using the "urn" scheme name
([RFC2141]).
NEW
reserving the term URN explicitly for the URIs using the "urn" scheme
name ([RFC2141]). This also reserves the string "urn" so that no IRI
scheme with that string may be registered.
#end
#end
#end
--
-------------------------+------------------
Reporter: evnikita2@… | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: 4395bis | Version:
Severity: - | Resolution:
Keywords: |
-------------------------+------------------

Ticket URL: <http://trac.tools.ietf.org/wg/iri/trac/ticket/69#comment:2>
iri <http://tools.ietf.org/wg/iri/>