Subject: FW: [MIB-DOCTORS] FW: [Ltru] Re: Language Tag MIB Textual Convention

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Fri, 10 Nov 2006 01:56:56 +0200

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 9:37 PM
To: Romascanu, Dan (Dan)
Cc: MIB Doctors; [email-masked]
Subject: Re: [MIB-DOCTORS] FW: [Ltru] Re: Language Tag MIB Textual
Convention

On Thu, Nov 09, 2006 at 08:59:09PM +0200, Romascanu, Dan (Dan) wrote:

> Uri ::= TEXTUAL-CONVENTION
>    DISPLAY-HINT "1024a"
>    STATUS      current
>    DESCRIPTION
>             "A Uniform Resource Identifier (URI) as defined by STD 66.
> 
>             Only lowercase characters are allowed.  The purpose of
this
>             restriction is to provide unique URIs for use as indexes.
>             URI normalization capitalizes letters in escape sequences,
>             but objects using this convention MUST use only lowercase.
> 
>             STD 66 URIs are of unlimited length.  This textual
>             convention imposes a length limit on the URIs that it can
>             represent."
>    REFERENCE "RFC 3986 STD 66 and RFC 3305"
>    SYNTAX      OCTET STRING (SIZE (1..1024))
> 
> Url ::= TEXTUAL-CONVENTION
>    DISPLAY-HINT "1024a"
>    STATUS      current
>    DESCRIPTION
>             "A Uniform Resource Locator (URL) as defined by STD 66.
> 
>             Only lowercase characters are allowed.  The purpose of
this
>             restriction is to provide unique URLs for use as indexes.
>             URL normalization capitalizes letters in escape sequences,
>             but objects using this convention MUST use only lowercase.
> 
>             STD 66 URLs are of unlimited length.  This textual
>             convention imposes a length limit on the URLs that it can
>             represent."
>    REFERENCE "RFC 3986 STD 66 and RFC 3305"
>    SYNTAX      OCTET STRING (SIZE (1..1024))

I have problems with these definitions:

a) I dislike the arbitrary length restriction. If needed, define TCs
such
   as Uri, Uri1024, Uri255 and so on so that MIB module writers can
choose
   how constrained they want to be. Unfortunately, the SMIv2 does not
   allow to "subtype" TCs, so this requires text duplication.

b) I think the requirements for lowercase characters is broken. We
should
   simply require normalized URIs as defined in section 6 of RFC 3986.
   (Note that only parts of a URI are actually case-insensitive and that
   there are other sources of variations for the same URI.)

c) I fail to see why we have a definition for a URI and a URL. RFC 3986
   says in section 1.1.3:

     [...] Future specifications and related documentation should
     use the general term "URI" rather than the more restrictive terms
     "URL" and "URN" [RFC3305].

   There is more text in the RFC which explains that the distinction of
   different classes of URIs is not very useful.

/js

-- 
Juergen Schoenwaelder		 International University Bremen
				 (Jacobs University Bremen as of Spring
2007)
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: Martin Duerst <[email-masked]>
Date: Fri, 10 Nov 2006 16:04:57 +0900

>   how constrained they want to be.

Good idea.

>   there are other sources of variations for the same URI.)

Very much so. In general, URIs are case sensitive. Also, in general,
there are occasions where every case in every character counts.
As an example, http://www.w3.org/1999/xhtml is the XML namespace
for XHTML 1.0. If you click on http://Www.w3.org/1999/xhtml
(note an uppercase 'W'), you get to the same page, but that URI
won't be accepted as the XHTML 1.0 namespace URI, because XML namespaces
are compared character-by-character, case-sensitively.

For more details on URI comparison, please see Section 6,
Normalization and Comparison, of http://www.ietf.org/rfc/rfc3986.txt.

>   different classes of URIs is not very useful.

I already agreed to that in another post!

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]