W3C home > Mailing lists > Public > uri@w3.org > April 2009

Re: [Uri-review] review requested for the YANG definition of a URI datatype

From: Larry Masinter <masinter@adobe.com>
Date: Wed, 1 Apr 2009 20:48:28 -0700
To: Martin J. Dürst <duerst@it.aoyama.ac.jp>
CC: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "uri-review@ietf.org" <uri-review@ietf.org>, Martin Bjorklund <mbj@tail-f.com>, David Partain <david@partain.se>, "uri@w3.org" <uri@w3.org>
Message-ID: <D09979E0-BC50-47C0-85CE-F41A3C75B8F6@adobe.com>
I'm not sure that "necessary" percent encoding is well defined

Sent from my iPhone

On Apr 1, 2009, at 7:22 PM, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>  
wrote:

> Hello Juergen,
>
> I think this is a question about generic URI syntax, and therefore
> should go to uri@w3.org (which I have cc'ed).
>
> Did you also consider having a datatype for IRIs?
>
> Regards,    Martin.
>
> P.S.: Please remove uri-review@ietf.org from the cc list when  
> replying.
>
> On 2009/04/01 18:12, Juergen Schoenwaelder wrote:
>> Hi,
>>
>> I am editor of a document defining among other things a URI data type
>> for the YANG data modeling language (NETMOD working group). Right  
>> now,
>> our definition looks as follows (<draft-ietf-netmod-yang-types-02>):
>>
>>    typedef uri {
>>      type string;    // [TODO] add the regex from RFC 3986 here?
>>      description
>>       "The uri type represents a Uniform Resource Identifier
>>        (URI) as defined by STD 66.
>>
>>        Objects using the uri type must be in US-ASCII encoding,
>>        and MUST be normalized as described by RFC 3986 Sections
>>        6.2.1, 6.2.2.1, and 6.2.2.2.  All unnecessary
>>        percent-encoding is removed, and all case-insensitive
>>        characters are set to lowercase except for hexadecimal
>>        digits, which are normalized to uppercase as described in
>>        Section 6.2.2.1.
>>
>>        The purpose of this normalization is to help provide
>>        unique URIs.  Note that this normalization is not
>>        sufficient to provide uniqueness.  Two URIs that are
>>        textually distinct after this normalization may still be
>>        equivalent.
>>
>>        Objects using the uri type may restrict the schemes that
>>        they permit.  For example, 'data:' and 'urn:' schemes
>>        might not be appropriate.
>>
>>        A zero-length URI is not a valid URI.  This can be used to
>>        express 'URI absent' where required
>>
>>        This type is in the value set and its semantics equivalent
>>        to the Uri textual convention of the SMIv2.";
>>      reference
>>       "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
>>        RFC 3305: Report from the Joint W3C/IETF URI Planning Interest
>>                  Group: Uniform Resource Identifiers (URIs), URLs,
>>                  and Uniform Resource Names (URNs): Clarifications
>>                  and Recommendations
>>        RFC 5017: MIB Textual Conventions for Uniform Resource
>>                  Identifiers (URIs)";
>>    }
>>
>> One particular question is whether it is safe to add the following
>> pattern restriction (XSD regular expression syntax):
>>
>>   type string {
>>     pattern '(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))? 
>> (#(.*))?';
>>   }
>>
>> The regular expression is taken from appendix B of RFC 3986.
>>
>> /js
>>
>
> -- 
> #-# Martin J.Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp
>
Received on Thursday, 2 April 2009 03:49:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:42 GMT