Subject: Criticisms of vnd draft

From: Ian King <[email-masked]>
Date: Wed, 17 Mar 1999 13:56:57 -0800

I've had some very welcome input from Leslie Daigle of URN fame :-)
regarding the vnd draft I mailed out last week.  I'll summarize and respond
to it in this mail.  

First, the vnd.* syntax uses the '.' as the separator for the keyword from
the rest of the scheme text; the procedures draft says the separator should
be a '-'.  We can either change the procedures draft to include '.', change
the vnd draft to use '-', or admit that life isn't perfect.  I'm planning to
do the third -- I'll add some text to the vnd draft stating that the '.' in
the vnd syntax is historical, and is at variance with the procedures draft.

I've also used language that sounds as if compliance with the URL guidelines
draft is somehow optional.  I did that deliberately at the time, although I
can't recall why; in any event, Leslie pointed it out, and I plan to change
it to make compliance with both the syntax draft and guidelines draft
required (people will do what they do anyway).  

The other point Leslie raised is one that is at least a close cousin to the
rats we battled in WG meetings: the vendor-ID string.  I added a bit of
language to the wording I lifted from the MIME doc, stating that IANA could
refuse to register a vendor-ID for several reasons, including that it wasn't
"representative" of the vendor.  We can go one of a few ways with this:  we
can leave it as undefined as it is in the MIME doc, we can try to make the
vnd draft language more prescriptive, or we can leave it alone.  One thought
I have here is that these URL scheme names are NOT intended for the address
bar of the browser; these are intended for the situation where a vendor
needs something human-transcribable (which, despite many arguments, OIDs and
GUIDs are not), for instance in a scripting environment (CGI or ASP, for
instance).  For this reason, I don't think the competition for "pretty
vendor-IDs" will be as keen as for "short-short" names.  I've tried to give
the IANA discretion to deny, for instance, Oracle using 'netscape' as a
vendor-ID.  In any event, I am asking IANA to create a separate registry for
these vendor-IDs, while the MIME scheme doesn't separate the vendor-ID from
the type name.  Does it work to more closely emulate the MIME approach, with
the vendor-ID "registration" being "implied" as part of the URL scheme name
use?  

I'm open to suggestions and discussion on this point, but please realize
that the vnd draft is not a product of the Working Group, and I'm asking for
your input as interested parties.  My inclination is to either change the
language to be closer to the MIME language I stole, or leave it alone and
take my chances.  :-)  

Thoughts?  Thanks -- Ian

Ian King <[email-masked]>
Internet Bill Delivery & Payment
MICROSOFT CORPORATION

---

From: Jon Knight <[email-masked]>
Date: Thu, 18 Mar 1999 09:41:29 +0000 (GMT)

> the vnd syntax is historical, and is at variance with the procedures draft.

Seeing as the vnd syntax is in a draft and the procedures is also a draft,
it seems a bit silly to not make them agree (doesn't set too good an
example for others to follow for one thing).  I'd say that we should
really do one of the other two options.  Personally I'd go with the first
option unless this is an example of a fault with the procedures draft
(which I don't think it is is it?).  As they are both draft documents
there shouldn't be a problem with any existing implementations (on the
grounds of the old "be it on your own head if you implement from an I-D"
rule).

Tatty bye,

Jim'll

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 19 Mar 1999 12:53:53 -0500 (EST)

Howdy,

One clarification:

> required (people will do what they do anyway).  

I caught this on in the URL REG document -- where it says that non
IETF tree URLs need not conform to URL syntax. Specifically:

> 3.3 Alternative Trees

[snip]
>   URL schemes created in an alternative tree are encouraged to conform
>   to the generic URL syntax, RFC 2396, but are not required to do so.
>   However, the tree's defining document must set forth the strength of
>   this requirement.  

We have a syntax standard -- we shouldn't actively condone ignoring it.

Leslie.

------------------------------------------------------------------------------

  "Never confuse                               Leslie Daigle
     an appreciation of the simple                              
              for                              Bunyip Information Systems Inc.
     a lack of understanding of the complex."  +1 514 285 0088
                  -- ThinkingCat               [email-masked]
 
------------------------------------------------------------------------------