Date: Mon, 19 Jan 1998 03:31:14 +0100
From: Tomas Fasth <tomas(_dot_)fasth(_at_)twinspot(_dot_)net>
Tim Showalter wrote:
I think a yes/no is enough, provided the interpreter can give a text
response explaining why. Trying to get a list of all the ways an
interpreter can fail is futile.
I don't think a yes/no with textual explaination will do.
I suggest we use yes/no together with a formally defined error
code/word. And why not line and column pointers as well.
The reason is to give the user agent a fair chance to guide the user
when trying to correct the error. Also, we can not assume the text
resonse is understood by the user, and I dont think we want to force UAs
to do language translations of free text messages. It has to be some
formality in that regard.
So you're saying that we can deliniate the failure conditions, assigning
each a failure code? What happens when you miss one? What happens when
the reporting agent can't understand one of them?
I believe that it's likely that the user will choose a filtering agent that
uses a language they understand. Providing a way to change the error
language would be necessary, and it's one more thing that has to go with
the script through the transport.
I think the transporting agent *should* validate the code, but there's no
way to enforce that.
I think *NOT*. I think the transport should be done transparently. A
responsibility for validation should *ONLY* exist at both ends of a
filter exchange. [...]
I think that the agent submitting code to the filtering agent should
validate code. (The meaning I meant to attach to "transporting agent"
wasn't the obvious one; sorry.)
Exchanging MIME messages over the mail transport infrastructure is one
such suggestion.
Standardizing on magic addresses worries me a little, but it's a
possibility. I'll note that if you have any problems with ACAP, you have
all the same problems with this -- impossible to validate the script.
--
Tim Showalter
tjs+(_at_)andrew(_dot_)cmu(_dot_)edu