]> HCL Software

300 Apollo Drive Chelmsford MA 01824 US dconmy@pnp-hcl.com

General Internet-Draft This document describes the 'notes' URI scheme. Specifically, it lays out the syntactic components and how those components are used by URI resolution to locate and view or edit a Notes resource, typically an application and/or document.

Goals The primary goal of the 'notes' URI is to view or edit a resource. Typically, a 'notes' URI would be encountered in MIME Email which contains links to other applications and/or documents residing on Domino server(s). A 'notes' URI can also be used with operating system clipboard operations to share a link with a native application or a browser application. When a 'notes' URI is clicked, a local installation of an application that supports the protocol will be launched and the resource will be located and shown.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Applications and/or Protocols which use this URI Scheme Name All HCL Notes, HCL Nomad, HCL Client Application Access, IBM Client Application Access, IBM Notes and Lotus Notes clients since 1999 have supported the 'notes' URI scheme.

Syntax Rules

General Syntax The 'notes' URI comes in several forms described below.

ABNF Grammar The full ABNF (certain values are included by reference from ):

Special Cases and Default Values

If a Server is not specified and an application or document is to be located In the case where the 'notes' URI does not contain a named server and the appReplicaID is specified, the client application SHOULD locate the specified application. In the case where the 'notes' URI does not contain a named server and an appFileAndPath is specified, the client applicaiton SHOULD locate a local copy of the application.

If a Server is specified but not available In the case where the 'notes' URI does contain a named server and the named server is currently unreachable, the client application MAY locate the resource on an alternate server as if the server were not specified. See

If a view or folder is not supplied In the case where the 'notes' URI does not contain a viewUNID, folderUNID or name, and the application initially shows a view or folder, the client application WILL choose a default.

If a view or form name is supplied Where available, a view or form alias should be used instead of the name shown in the user interface.

If a viewUNID or folderUNID of 0 is supplied In this case, the document is still opened.

If OpenForm is specified A 'notes' URI of type formDocNew will create a new document in the user interface using the specified form.

Encoding Rules The server, appFileAndPath and name must be encoded using the UTF-8 encoding scheme, and any octet that is not one of the permitted characters per the above grammar MUST instead be represented by a "%" followed by two characters from the <hex> character set above. The two characters give the hexadecimal representation of that octet. The maximum length of a view or form name is 64 bytes after decoding.

Case sensitivity of URI components The values of server, appFileAndPath and name are case insensitive. For clarity, the actual case of the underlying resource SHOULD be used but is not REQUIRED.

Examples

Application Examples

Document Examples

Application User Interface Examples

Security Considerations All operations initiated as a result of locating and viewing a 'notes' URI are done so under the access rights of the user logged into the client application. All access restrictions including application access control list , readers fields and execution control lists are in effect when locating the application and/or document referred to by a 'notes' URI.

IANA Considerations The IANA is asked to register the URL registration template found in in accordance with

Appendix A: Registration Template Resource Identifier (RI) Scheme name: notes Status: provisional Scheme syntax: Encoding considerations: Intended usage: Applications and/or protocols which use this scheme: Interoperability considerations: None not specified Security considerations:

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. [STANDARDS-TRACK] The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3979, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References n.d.