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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Thu, 02 April 2009 02:19 UTC

Message-ID: <49D420EA.5090906@it.aoyama.ac.jp>
Date: Thu, 02 Apr 2009 11:20:26 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre
MIME-Version: 1.0
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
References: <20090401091257.GC15362@elstar.local>
In-Reply-To: <20090401091257.GC15362@elstar.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: uri-review@ietf.org, Martin Bjorklund <mbj@tail-f.com>, "uri@w3.org" <uri@w3.org>, David Partain <david@partain.se>
Subject: Re: [Uri-review] review requested for the YANG definition of a URI datatype
Precedence: list

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

[Uri-review] review requested for the YANG defini… Juergen Schoenwaelder
Re: [Uri-review] review requested for the YANG de… Martin J. Dürst
Re: [Uri-review] review requested for the YANG de… Larry Masinter