Re: Holding connections open; syntax ambiguity?

[Peter Deutsch <[e-mail]>]

[ You wrote: ]
.  .  .
> I've looked around, but haven't seen a complete list of the proposed
> required constraints. .  .  .

I'm working on it as we speak. I didn't want to post it
half baked, but should be done in another day or two.

Tentative set currently includes but is not limited to:


/* Search control, default would be exact, case sensitive??? */

SEARCH=		{exact |substring | fuzzy | regex | <X-format> }
CASE=		{ sensitive | insensitive }


/* Output format specifier. Defaults specified in text. */

FORMAT=		{full | abridged | handle | summary | 
		   pointer | mime | <X-format> }


/* authentication support options */

AUTHENTICATE=	{password | ticket |  kerberos | <X-format> }
PASSWORD=	<string>
NAME=		<string>
<some more stuff for authentication schemes here>


/* language support options */

INCHARSET=	{TBD, see MIME}
OUTCHARSET=	{TBD, see MIME}
LANGUAGE=	{TBD, see MIME}


/* general constraints */

MAXHITS=	{1-some large n??}
HOLD



I think there's surely more, but I haven't finished that
portion of the document yet. Additions, comments etc on
this list are most welcome....


> .  .  . I imagine a query like
>     john doe, HOLD, FUZZY, MAXHITS=2
> would be about right for incremental search.

Close, although we currently have not been discussing how
to handle white space in a query, as you are doing here. I
think we'll need to specify a simple quoting mechanism to
allow for this, since I seem to recall Joan's document
specifies that we run such terms together and remove the
whitespace.

Adding in Mark's proposal for better structuring
constraints and options we get something more along the
lines of:


	"John Doe", HOLD, SEARCH=fuzzy, MAXHITS=2

Which implies a SEARCH-ALL for John Doe. It would probably
be better written as:

	NAME="John Doe", HOLD, SEARCH=fuzzy, MAXHITS=2

> Come to think of it, it seems that comma is a bad choice to set off options,
> since it is used to set off first names (according to an early document on
> the servers).  How does one handle people whose first names
> are equal to keywords?  One of my friends is called Fuzzy; would
>     smith, fuzzy, FUZZY
> find her?  Perhaps slashes are less ambiguous:
>     smith, fuzzy /FUZZY
> or does that remind people too much of VMS?

I don't recall ever having multiple search names like
this, since they seem to imply a logical OR operation
(which BTW was soundly denounced at the meeting in
Columbus as unwanted complexity).  We _do_ allow multiple
search terms, but these are separated by ';', and are
ANDed, not ORed.

I think someone (Mark?) did at one point post a sample
query that looked like this, but I don't think it''s not
part of the current proposal. 

Or am I missing something here? I really should go home...

If I don't hear otherwise from the list, I'll assume
clarification on using white space and a corresponding
quoting mechanism are wanted and wordsmith something in.
Get out those voting cards now, folks!



				- peterd

-- 
------------------------------------------------------------------------------
Peter Deutsch,                                       [e-mail]
President,                                        [phone]  (phone)
Bunyip Information Systems Inc.                    [phone]  (fax)

  "any sufficiently advanced magic is indistinguishable from technology"
           (- with apologies to Arthur C. Clarke, who almost got it right...)
------------------------------------------------------------------------------