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

[Ned Freed <ned.freed@xxxxxxxxxxx>]

> 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.

While I agree it's a good idea to report errors at as early a phase as
possible, unless we're willing to specify that variable substitutions cannot be 
used in list names, this can at most be a SHOULD, not a MUST.

> 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.

Agreed, however, it isn't clear to me that throwing an error is the right
thing to do when a given list resource is unavailable. Handling the
unavailability of a given resource is well within the purview of a properly
constructed portable script, I should think.

> 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.

It's unclear what "support" means in this context. In our implementtation list
URIs are parsed and then passed to what amounts to a callout. We can of course
make it so tag: is always a legal URL type when that check is done, but we
cannot force tag: to work.

> --------------------------------------------------------------------------
> [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.

See above. This needs to be a SHOULD.

>    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.

If we're going to throw an error like this in a  test I think we need a way to
test and see if the resource is available.

>    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.

I think some elaboration on what "support" means would be good here.

> 2.4.2 Other URI Schemes

>    Implementations MAY support other URI schemes.


				Ned