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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [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/>


Reply | Threaded
Open this post in threaded view
|

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

Peter Saint-Andre-2
On 1/10/12 5:28 PM, iri issue tracker wrote:
> #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."

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
http://stpeter.im/



Reply | Threaded
Open this post in threaded view
|

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

Peter Saint-Andre-2
On 1/10/12 5:36 PM, Peter Saint-Andre wrote:

> On 1/10/12 5:28 PM, iri issue tracker wrote:
>> #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."
>
> 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

--
Peter Saint-Andre
https://stpeter.im/





Reply | Threaded
Open this post in threaded view
|

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

Bjoern Hoehrmann
* Peter Saint-Andre wrote:
>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.

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?
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

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

Peter Saint-Andre-2
On 6/6/12 4:00 PM, Bjoern Hoehrmann wrote:

> * Peter Saint-Andre wrote:
>> 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.
>
> 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

--
Peter Saint-Andre
https://stpeter.im/





Reply | Threaded
Open this post in threaded view
|

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

Ted Hardie-2
In reply to this post by Peter Saint-Andre-2
On Wed, Jun 6, 2012 at 11:09 PM, Peter Saint-Andre <[hidden email]> wrote:

> On 1/10/12 5:36 PM, Peter Saint-Andre wrote:
>> 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:

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

Reply | Threaded
Open this post in threaded view
|

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

Peter Saint-Andre-2
On 6/7/12 1:36 AM, Ted Hardie wrote:

> On Wed, Jun 6, 2012 at 11:09 PM, Peter Saint-Andre <[hidden email]> wrote:
>> On 1/10/12 5:36 PM, Peter Saint-Andre wrote:
>>> 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:
>
> 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

--
Peter Saint-Andre
https://stpeter.im/





Reply | Threaded
Open this post in threaded view
|

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

masinter
+1 me too.


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






Reply | Threaded
Open this post in threaded view
|

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

iri issue tracker
In reply to this post by 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:
 ----

 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".
  #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/>