[draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling Clarifications

[Robert Burrell Donkin <[e-mail]>]

Proposal: Separate Section For Discussion of TAG
=================================================
Changes
-------
Split first paragraph into sections.
Rationale
---------
Clarity

Proposal: Clarify Expected Error Handling Behaviour
===================================================
Changes
-------
Specify that unsupported URI schemas are compile time
errors and that resolution failures are runtime errors.
Rationale
---------
Practical implementations will not be able to support
all feasible URI schemes, protocols, discovery mechanisms
and resource semantics.

Any URI schema which is not supported by the engine
will never be resolved. In this case, it is clearer and
cleaner to fail at compile time. Note that this case
also includes malformed URIs.

Resources may be dynamic. A resource whose semantics
could not be understood at compile time may have been
replaced by one that could be at runtime. Resource
resolution may be dynamic: a resource which could not
be resolved at compile time may be resolvable at
runtime. Services may be dynamic. A service with
suitable semantics may become available at runtime
which was not at compile time. Conversely,
resources, resource resolution and service discovery
may fail at runtime after it succeeded at compile
time.

So, failures to resolve, locate or parse a resource
referred to by the script should only be raised at
runtime.

Proposal: Require Implementations To Support [TAG-URI]
======================================================
Changes
-------
Require that all implementations support tag, plus any other
URI schemes of their choice.
Rationale
---------
Insisting that implementations support at least one protocol
sets a minimum level for script portability. Picking one
particular web protocol such as LDAP, HTTP or FTP would impose
a unnecessary burden on implementations and
unnecessarily involve the specification in the semantics of
engine-list server interactions.

A credible alternative choice would be relative URIs.


--------------------------------------------------------------------------
[1] Proposal
--------------------------------------------------------------------------

2.4.  Syntax of an externally stored list name

   A name of an externally stored list is always an absolute URI [URI].
   Implementations might find URLs such as [LDAP], [CardDAV], or
   [TAG-URI] to be useful for naming external lists.

   Implementations MUST raise a compile time error when a list name
   cannot be parsed into a URI scheme supported by the implementation.

   Resolution of the resource MAY involve resource location and service
   discovery. Resources MAY change dynamically. Resolution of the
   resource MUST be perform at script execution time. When the resource
   cannot be located or the resource type is found to be unsupported
   then the implementation MUST raise a runtime error.

   Implementations MAY attempt to resolve the URI at compile time but
   MUST NOT raise a compile time error on failure.

2.4.1 The Tag Scheme
   The "tag" URI scheme [TAG-URI] can be used to represent opaque, but
   user friendlier identifiers.

   Resolution of such identifiers is going to be implementation specific
   and it can help in hiding the complexity of an implementation from
   end users.  For example, an implementation can provide a web interface
   for managing lists of users stored in LDAP.  Requiring users to know
   generic LDAP URL syntax might not be very practical, due to its
   complexity.  An implementation can instead use a fixed tag URI prefix
   such as "tag:example.com,<date>:" (where <date> can be, for example,
   a date generated once on installation of the web interface and left
   untouched upon upgrades) and the prefix doesn't even need to be shown
   to end users.

   Implementations MUST support the [TAG-URI] URI scheme.

2.4.2 Other URI Schemes

   Implementations MAY support other URI schemes.

--------------------------------------------------------------------------
[2] Original Text
--------------------------------------------------------------------------

2.4.  Syntax of an externally stored list name

   A name of an externally stored list is always an absolute URI [URI].
   Implementations might find URLs such as [LDAP], [CardDAV], or
   [TAG-URI] to be useful for naming external lists.
   The "tag" URI scheme [TAG-URI] can be used to represent opaque, but
   user friendlier identifiers.  Resolution of such identifiers is going
   to be implementation specific and it can help in hiding the
   complexity of an implementation from end users.  For example, an
   implementation can provide a web interface for managing lists of
   users stored in LDAP.  Requiring users to know generic LDAP URL
   syntax might not be very practical, due to its complexity.  An
   implementation can instead use a fixed tag URI prefix such as "tag:
   example.com,<date>:" (where <date> can be, for example, a date
   generated once on installation of the web interface and left
   untouched upon upgrades) and the prefix doesn't even need to be shown
   to end users.