An alternative URL scheme tree: vnd.*

Many times, we've discussed alternative URL scheme name syntaxes, and the
vnd.* syntax has been cited as one in common use.  The registration draft
outlines a procedure for creating a new tree, so to see how well we've
wrought, I created the following draft for vnd.*.  

One thing that was quite interesting: it was a lot easier than I expected to
write this.  Separating this task from the main procedures draft made it
possible to concentrate on the requirements of this tree, rather than trying
to generalize as we did in early drafts of the procedures doc.  This gives
me confidence that we have actually created a good process here.  

Please get any comments to me ASAP, as I want to submit this no later than
the end of the week.  I know I missed the general drafts deadline for the
meeting, but I'd still like to get this into circulation so we can get input
from others outside URLREG, hopefully at the meeting; I think this will help
us conclude the work of the WG.  Thanks.  

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

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

INTERNET-DRAFT                                                  I. King
<draft-ietf-vnd-urlscheme-00.txt>                 Microsoft Corporation
                                                          March 5, 1999



			The VND Tree for URL Scheme Names



Status of this Memo

	This document is an Internet-Draft and is in full conformance with
all 
	provisions of Section 10 of RFC2026.

	Internet-Drafts are working documents of the Internet Engineering
Task Force 
	(IETF), its areas, and its working groups. Note that other groups
may also 
	distribute working documents as Internet-Drafts. 

	Internet-Drafts are draft documents valid for a maximum of six
months and may 
	be updated, replaced, or obsoleted by other documents at any time.
It is 
	inappropriate to use Internet-Drafts as reference material or to
cite them 
	other than as "work in progress." 

	The list of current Internet-Drafts can be accessed at 
	http://www.ietf.org/ietf/1id-abstracts.txt. 

	The list of Internet-Draft Shadow Directories can be accessed at 
	http://www.ietf.org/shadow.html.

	This Internet-Draft expires September 5, 1999.

Copyright Notice

	Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

	This document describes the vnd scheme namespace, or "tree," which
provides 
	for vendor-specific URL scheme namespaces with relaxed registration 
	requirements, which can be used with no concern for name collision.
The 
	namespace also implicitly provides identification of the originator
of the 
	URL scheme, in the event others become interested in the scheme. 

1.0 Introduction

	The URL scheme name registration process, described in RFC
[URL-PROCESS][1] 
	requires IESG review and approval of all proposed scheme names
within the 
	"IETF tree", which encompasses simple, short, often descriptive URL
scheme 
	names (such as http:, fax:, or mailto:).  This is intended to allow
for 
	considered public review of proposals which would associate a
commonly-used 
	label with a URL scheme, and to avoid collision and multiple
implementations 
	in the URL scheme namespace.  However, this form of URL scheme name
is often 
	selected because the name is intended to be widely distributed, seen
and 
	used, possibly by naive users.  In the development of new products,
vendors 
	often have the need to use URLs to identify and locate resources in
a manner 
	that is NOT seen by end users, is not widely distributed, or for
some other 
	reason does not justify the effort to register a scheme name from
the IETF 
	tree.  

	One approach which has been used informally for some time is what we
may call 
	the vnd scheme name tree.  URL scheme names in this tree are
characterized by 
	the initial string 'vnd', followed by a separator '.' and thence by
an 
	abbreviation identifying a particular vendor.  For example,
Microsoft has 
	made use of 'vnd.ms' as a URL scheme namespace, creating new scheme
names by 
	appending another separator '.' and a unique string (for example, 
	vnd.ms.foo:).  This parallels syntax documented for MIME type naming
in RFC 
	2048 [2].  

	This document shall formalize the use of the vnd scheme name syntax,
defining 
	the vnd scheme name tree as one parallel to the IETF tree, with
unique 
	requirements for registration and management.  

2.0 VND Scheme Name Syntax

2.1 General Syntax

	The general syntax of a URL scheme name in conformance with the vnd
tree is:

				'vnd.'<vendor-ID>'.'<scheme-ID>

	where vnd is a reserved prefix that uniquely identifies a URL scheme
name 
	belonging to this tree, the vendor-ID is a string registered with
IANA to 
	uniquely identify an organization, and the scheme-ID is a string of
US-ASCII 
	characters, in conformance with RFC 2396[3] and RFC
[URL-GUIDELINES], that 
	identifies the particular scheme within the subtree owned by the
organization 
	identified by <vendor-ID>.  All parts are case-insensitive.  

	This syntax specifically disallows the form `vnd.foo', where `foo'
is the 
	scheme-ID and there is no vendor-ID.  If a scheme is to be widely
shared, it 
	should either be owned by one vendor and shared with others by
agreement, or 
	should be registered within the IETF tree.  The sole purpose for the
vnd tree 
	is to support vendor-specific URL scheme namespaces.  

2.2 Choosing a vendor-ID

	The vendor-ID is a short string of US-ASCII characters that is
sufficient to 
	uniquely identify the organization.  The vendor-ID string may
consist only of 
	alphanumeric characters, and the first character must be alphabetic.
In 
	particular, the character `.' is specifically disallowed.  The
vendor-ID must 
	be registered with IANA, and IANA may disapprove a registration for
failure 
	to meet syntax rules, for conflict or confusion with another
vendor-ID, for 
	being an inappropriate identifier for the vendor (for instance, if
Microsoft 
	sought to use the vendor-ID `sun'), or for being objectionable in
some other 
	way (for instance, a word generally considered profane or
offensive).  
	Vendors are encouraged to establish only one vendor-ID, although it
is 
	recognized that large organizations may actually consist of multiple
sub-
	units. 

	The organization may be a business (whether for-profit or not),
governmental 
	unit, educational institution, or any other entity which is
regularly engaged 
	in producing software.  The term "vendor" is used in this document
for 
	simplicity.  

2.3 Syntax for the scheme-ID

	The scheme-ID must comply with RFC 2396 and should comply with RFC
[URL-
	GUIDELINES].  

3.0 Requirements for Scheme Name Registration

3.1 General Requirements

	These requirements are modeled upon those for MIME types, as set
forth in RFC 
	2048.  The purpose of registration is to give notice to the Internet

	community of the existence of the vnd subtree and of the new scheme.

	Registration of the vendor-ID is required, and serves to partition
the 
	namespace (and avoid collision).  Registration of the specific
scheme is 
	optional, and may be anything in the range from notice that the name
is in 
	use, to a full specification of the scheme's syntax and semantics.  

3.2 Registering the vendor-ID

	The request for vendor-ID registration may be included in a vnd URL
scheme 
	name registration, or may be separately submitted, to IANA at
[email protected]. 
	The request must contain the proposed vendor-ID, the vendor's legal
business 
	name, principal business address, telephone number, and contact
information 
	for a person or position that will be responsible for the use of the
vendor's 
	subtree.  The vendor should inform IANA if changes in business
(acquisition, 
	closure, etc.) lead to changes in this information, and may
expressly 
	transfer ownership of its vendor-ID and associated subtree upon such
changes 
	or for any other reason.  

	A given vendor-ID can be issued only once, and it does not expire;
however, 
	if IANA becomes aware that the entity so identified is no longer in 
	existence, and no express transfer of the vendor-ID registration was

	performed, IANA may declare a given registration `archived'.  This
is to 
	avoid possible name collision; if vendor B were allowed to
re-register vendor 
	A's vendor-ID (with no contact between the vendors), and vendor A's
products 
	were still used, vendor B might ignorantly redefine a URL scheme in
a way 
	that breaks vendor A's products.  

	IANA will maintain a public registry of the vendor-IDs that have
been 
	assigned, together with contact information.  

3.3 Publishing Scheme-Specific Information

	While public exposure and review of a URL scheme created in the vnd
tree is 
	not required, using the IETF Internet-Draft mechanism for peer
review is 
	strongly encouraged to improve the quality of the specification.
RFC 
	publication of vnd tree URL schemes is encouraged but not required.
Material 
	may be published as an Informational RFC by sending it to the RFC
Editor 
	(please follow the instructions to RFC authors, RFC 2223 [5]).  

	Another useful mechanism for disseminating information about a new
vnd URL 
	scheme is publication on the ietf-announce mailing list.  This is
encouraged 
	for URL schemes which a vendor believes might be of general interest
to the 
	Internet community at some point in the future, but is discouraged
if the URL 
	scheme name is expected to be visible to end users.  In the case of
a URL 
	scheme name that is intended to be transcribed and otherwise used by
end 
	users, a name should be registered in the IETF tree pursuant to RFC
[URL-
	PROCESS].  

	IANA will maintain a public registry of vnd tree scheme names that
have been 
	published by either of the above methods.  

	In publishing information about a new vnd URL scheme, vendors are
encouraged 
	to follow the guidelines set forth in section 6 of RFC
[URL-PROCESS].  

3.4 Change Control

	The vendor is the owner of all schemes within its tree and has sole 
	responsibility for management of the sub-tree created by its
vendor-ID, and 
	owns change control for any URL schemes deployed therein.  No one
may 
	implement or deploy a URL scheme in a vnd scheme namespace to which
one is 
	not entitled by virtue of association with the vendor.  If a vendor
publishes 
	information about a vnd URL scheme by either of the methods
described in 
	section 3.3 above, changes to the syntax or semantics of that URL
scheme must 
	be subsequently published by the same medium as originally employed.


4.0 Security Considerations

	The vendor identified by the vendor-ID part of the URL scheme name
should be 
	consulted for any information regarding the URL scheme and its 
	implementation.  To that end, vendors must provide a point of
contact that 
	can be reasonably authenticated, for instance, common business
contact 
	information (business address, telephone number, etc.).  (This is
addressed 
	in the registration section above.)  

	No vendor is required by reason of registration in the vnd tree, by
either 
	means, to disclose syntactical or other information about schemes it
has 
	developed.  Security considerations for individual schemes may vary,
and the 
	vendor is not required to publish same.  Notwithstanding, the vendor
is 
	highly encouraged to publish any known security issues, and to
comply with 
	the security considerations set forth in RFC [URL-GUIDELINES].  

	Vendors should exercise caution around the security risks posed by a
given 
	URL scheme, and take steps to protect themselves against damage
caused by 
	ignorant use of the URL scheme by others.  In other words, if the
URL scheme 
	has not been published, together with its security considerations,
the vendor 
	is probably best served by avoiding use which would expose the
scheme to 
	others (i.e. on the open Internet).  Likewise, caution should be
exercised in 
	using a vnd URL scheme if one cannot obtain information on its
syntax and 
	semantics; uninformed use may have unexpected impact.  

5.0 References

[1]	Petke, R., King, I., "Registration Procedures for URL Scheme Names",
RFC 
	[URL-PROCESS], November 1998

[2]	Freed, N., Klensin, J., Postel, J., "Multipurpose Internet Mail
Extensions 
	(MIME) Part Four: Registration Procedures", RFC 2048, November 1996

[3]	Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., "Guidelines
for New 
	URL Schemes", RFC [URL-GUIDELINES], August 1998

[4]	Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
Identifiers 
	(URI): Generic Syntax", RFC 2396, August 1998

[5]	Postel, J., Reynolds, J., "Instructions to RFC Authors", RFC 2223,
October 
	1997.


6.0  Author's Address

   Ian King
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   USA
   Phone:	+1 425-703-2293
   FAX:		+1 425-936-7329
   Email: [email protected]