This page is edited as plaintext.
Network Working Group Request for Comments: Category: Editors: Leo Sauermann Contributors: Pär Lannerö, KTH Sweden Malte Kiesel, DFKI GmbH The Desktop URI scheme Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document specifies defines the "desktop" Uniform Resource Identifier (URI) scheme for desktop resources, used to identify resources on desktop operating systems within RDF. The scheme is used to identify resources within databases or desktop applications, that are not captured by file: //([RFC1738]) Ways to retrieve RDF representations via a desktop resolving protocol are suggested. Introduction The desktop uri scheme is used to identify desktop resources that are not identifyable using existing uri schemes, such as file:// or http://. These resources are typically stored by personal informaiton management applications, such as a calendar application or an e-mail client. Using this scheme, such applications can now expose URIs for managed resources, such as individual e-mail messages. There are existing schemes that serve as an input but cannot be used for this approach: file: //would allow to identify files and may be extended to identify further resources, as this is done on the unix filesystem to identify system handles. But this would require to find a hook in the filesystem where to host such desktop resources, which is hard to find and platform specific. Magnet [http://magnet-uri.sourceforge.net/ http://magnet-uri.sourceforge.net/magnet-draft-overview.txt does allow to identify arbitrary resources based on metadata values. This examples show how magnet works: magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&dn=Great+Speeches+-+Martin+Luther+King+Jr.+-+I+Have+A+Dream.mp3 magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C Magnet is already registered and in use by filesharing platforms, registering the same for multiple desktop applications would collide with the existing magnet: handlers. we cannot use RFC1738 because they are not capture there, we cannot use "info:" http://www.rfc-editor.org/rfc/rfc4452.txt because they are not to be registered, and we cannot use "urn:" http://www.rfc-editor.org/rfc/rfc2141.txt because our identifiers are location dependent. We cannot use HTTP URIs, because desktops have changing DNS names, so the URI will change once you switch network. And HTTP uris are not retrievable for desktop pcs. Even with the hacks we thought of, it is not clean. The HTTP port for a desktop may be blocked or multiple users on one machine may collide ports. Also, opening an http server on the desktop may be a security risk in # many environments. HTTP can not be used because other protocol handlers are already registered on the desktop to open/get data based on HTTP. We also won't have a HTTP server on the desktop. HTTP is a protocol for the web, not for one single desktop. And, there is the file:// uri scheme standardized by IETF that shows how to do it. http is not the silver bullet on the desktop. we cannot use XRI because it just adds complexity to HTTP dereferencing and others argumented that it is not needed for our case: http://www.w3.org/2001/tag/doc/URNsAndRegistries-50 1. The "desktop" URI scheme Semantic Desktop URIs have several parts, including an application specific part, hostname information and a path within the application's namespace. The name "desktop" stems from the requirement to identify resources for further annotations using the RDF technology. On desktops that are not aware of annotations or semantic databases, a way of uniquely identifying resources is also handy, thus it is not required to run RDF applications to use the desktop URI scheme. The scheme is intended to be used by desktop search engines to identify resources from desktop applications. This allows resources to be identified independent of implementation. This RFC uses a similar approach to URIs as the HTTP RFC: URIs in HTTP can be represented in absolute form or relative to some known base URI [11], depending upon the context of their use. The two forms are differentiated by the fact that absolute URIs always begin with a scheme name followed by a colon. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs 1738 [4] and RFC 1808 [11]). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", and "authority" from that specification. The elements of a desktop uri are: desktop://[[user@]host]/[application]/[abs_path] [user@] identifies the user at the host, optional. The username depends on theoperating system's user management. The username is needed to identifyresources kept by multiple users on the same desktop computer. [host] identifies the desktop computer using the DNS name or the IP address.This part is optional, as most personal computers have changing names andusers are not aware of their name, also when users switch their network theIP address or hostname may change (especially with dialup connections)Use the [host] part only when the hostname is a registered DNS name andstatically configured for the desktop computer. [application] - a unique string identifying the application that managesthe resource. A string is allowed with the same restrictions asdomain names (hostnames): alphanumerical, "-" and ".".see RFC 1034 for details. It is preferred to use domain namesas application identifiers that are related to the maker of the application.An Informal registry of application names is hosted athttp://www.semanticdesktop.org. It is possible to use non-standardapplication identifiers.The registry can also be hosted by IANA, we see two possible points whereto extend:http://www.dns-sd.org/ServiceTypes.html - service types as known to DNS(desktop would be one)http://www.iana.org/assignments/media-types/application/ - MIME-types(this does not suit our approach completly, as MIME is about encodingand not identifying, but is a good start)registered application identifers are (experimental, under frequent change)://* kde.org - items within the K Desktop environment, KAddressBook, etc* outlook.microsoft.com - resources within microsoft outlook* email - identifying e-mails within local desktop e-mail clients.Each client has to register at the operating system, one scheme is used [abs_path] the Path identifies the resource uniquely within the application.The same restrictions apply as within RFC 2396 and RFC 2616.1.1 ExamplesFor msoutlook:desktop:/outlook.microsoft.com/item/00000000ECD4B99358B9814B9DAFE2255CD8AE9A44B42F00desktop:///outlook.microsoft.com/folder/00000000ECD4B99358B9814B9DAFE2255CD8AE9A44B42F00for e-mails:The emails can either be identified by their message-id, their folder,or their standardized IMAP URI.desktop:///email/messageid:[mailto:23979723@example.com|23979723@example.com] desktop:///email/imap://[mailto:joe@example.com|joe@example.com]/INBOX;45 Arguments about wrapping IMAP URIs within desktop:///email: * we can assume that applications won't register for IMAP at the OS and that, if they do, the semantics of IMAP would be in place, so opening an e-mail for reading by the user won't be implemented as part of a client-server protocol * an e-mail client may use multiple ways of identification inside, either message-ids or IMAP uris. The client should be able to expose this approach in its URIs, to allow reuse. 2 Retrieval and opening of resources 2.1 GET Operating systems or services running on the OS have to provide ways to retrieve a description of the identified resource. The retrieval method is similar to HTTP-GET. We cannot propose a definitive standard, as each operating system has different approaches, but the protocol should somehow go like this: GET desktop:/email/messageid:[mailto:23979723@example.com|23979723@example.com] accept: application/rdf+xml Implementations use existing protocols (operating system calls, DLLs, DBUS messages, etc) to provide this functionality, but are platform dependent. 2.2 START An operating system service may implement methods to open resources identified using the desktop URI scheme: START desktop:/email/messageid:[mailto:23979723@example.com|23979723@example.com] This call will invoke a desktop application to show the identified resource to the user
