Proposed Changes in URI Scheme Registration Workshop by Stuart Weibel

1. DCC Workshop on Persistent IdentifiersURI Scheme RegistrationProposed Changes Stuart Weibel Senior Research Scientist July 1, 2005

2. URI Protocols • Web protocols emerged based roughly on what had worked thus far on the Internet, and informed by the hyperlinking idioms of Berners-Lee (and Englebart before him). • Challenge: • maintain compatibility with existing protocols, character sets, and applications • Maturation into theoretically sound and pragmatically useful tools • Architecture which sustains legacy and supports innovation

3. Its all Well designed and rational, no…? • The definitive roadmap of web architecture: Architecture of the World Wide Web, Volume One W3C Recommendation 15 December 2004 Can you say “retrofit”?

4. How we got here • There used to be URLs, URNs, and URCs (well, almost) • Uniform Resource Identifiers • URLs (Locators) • URNs (Names) • IRIs (a URI that knows the world has more than one language) URI = SCHEME, HOST, and PATH connected suitably Bonus points to any (except John Kunze) if you know what ‘URC’ means

5. Location, Location, Location… • You’ll never hear an Estate Agent say: “Identifiers, Identifiers, Identifiers “Get me” is more compelling than “tell me truly who you are for all time” • But Locators are not the same as Identifiers or are they? Well, no… but….

6. ftp File Transfer Protocol http Hypertext Transfer Protocol gopher The Gopher Protocol mailto Electronic mail address news USENET news nntp USENET news using NNTP access telnet Reference to interactive sessions wais Wide Area Information prospero Prospero Directory z39.50s Z39.50 z39.50r Z39.50 Retrieval cid content identifier mid message identifier vemmi versatile multimedia Interfaceservice service location imap internet message access protocol nfs network file system protocol acap application configuration access protocolrtsp real time streaming protocol tip Transaction Internet Protocol pop Post Office Protocol v3 data data dav dav opaquelocktoken opaquelocktoken sip session initiation protocol sips secure session intitiaion protocol tel telephone fax fax modem modem ldap Lightweight Directory Access Protocol https Hypertext Transfer Protocol Secure soap.beep soap.beep soap.beeps soap.beeps xmlrpc.beep xmlrpc.beeps xmlrpc.beeps xmlrpc.beeps urn Uniform Resource Names go go h323 H.323 ipp Internet Printing Protocol tftp Trivial File Transfer Protocol mupdate Mailbox Update (MUPDATE) Protocol pres Presence im Instant Messaging mtqp Message Tracking Query Protocol iris.beep iris.beep dict dictionary service protocol snmp Simple Network Management Protocol crid TV-Anytime Content Reference Identifier tag tag Reserved URI Scheme Names: afs Andrew File System global file names tn3270 Interactive 3270 emulation sessions mailserver Access to data available from mail servers URI Schemes (as of 2005 06 03) http://www.iana.org/assignments/uri-schemes

7. Guidelines and Registration Procedures for New URI Schemes http://ietfreport.isoc.org/all-ids/draft-hansen-2717bis-2718bis-uri-guidelines-04.txt • Proposed RFC regulating the registration of new URI schemes • Currently an Internet Draft (ID) • Approval will change substantially the procedure for registering new URI schemes

8. Motivations for a new procedure • New URI schemes are introduced on an experimental basis (or with entrepreneurial designs) without being registered (wild-type URIs) • Introducing a new scheme requires scarce knowledge and formidable documentation • The Keepers of the Gates are overburdened – long lead times and backlogs are disincentives to registration • Wild-type URI schemes raise the prospect of name collisions

9. The Strategy • Prevailing technological ideology embodies a strong bias against new URI schemes • But, better that new schemes be registered than not, so: • Stratify URI schemes • Permanent – maintain high bar for approval • Provisional – allow registration via simpler procedures • Historical – seen any gopher: or wais: lately? • Eliminates the notion of possible “alternative trees” in the IETF hierarchy (different namespaces)

10. Permanent Scheme Registration Requirements • “Clear Utility” to the “broad Internet community” • Conformance to existing syntax • Well defined behaviors and operations • Character encodings defined (especially with regards to internationalisation issues) • Analysis of Security considerations • Scheme names we (IANA) likes • Stay away from coca-cola: • Short, descriptive (?!?)

11. Provisional Scheme Registrations • Recommend all the stuff from Permanent Schemes, but if you can’t manage it, tell us why • Same scheme name and security considerations (sort of)

12. Registration Procedure • Check IANA registry for name collisions • URI registration ‘template’ • Mailing list review (URI@W3.ORG) is recommended • Submit to IANA after mailing list review • IANA initiates Expert Review • Expert Review recommends either permanent or provisional status • Scheme name registered (unless application is rejected)

13. And this is all going to work better… Isn’t it? • Making URI scheme registrations more ‘mechanical’ in nature will reduce costs and substantially improve IETF throughput (backlog is now 1-2 years) • Will there be a ‘land grab’ of choice scheme names, or a proliferation of semi-useful schemes? • Who will it hurt, and is a ‘marketplace’ of scheme names a good or bad thing? We shall see