[Digir-dev] RE: protocol schema proposal

[Dave V. <vie...@uk...>]

> -----Original Message-----
> From: P.J. Schwartz [mailto:pschwartz@CalAcademy.org]
> Sent: Wednesday, October 31, 2001 10:56
> To: Dave Vieglais
> Cc: dig...@so...
> Subject: RE: protocol schema proposal
> 
> 
> hey dave,
> 
> sorry for not answering this one right away.  anyway, comments
> interspersed below...
> 
> On Sun, 28 Oct 2001, Dave Vieglais wrote:
> 
...
> 
> > >     <header>
> > >       <requestType>search</requestType>
> > >     </header>
> >
> > Following the logic you use below for streamlining the filter
structure,
> > there's really no need for the <header> since the operation is
implied
> > by the <search> element in the document.  Is there a good reason for
> > keeping the <header> structure?
> 
> this is quite possibly true, although i'm not certain if we ever
decided
> that we should have more items in the header as originally suggested
in
> the weekend meeting.  have those items, such as send time, source, and
> destination been definatively thrown out?  have we no other reason to
keep
> the header?


I think sendTime was tossed because it excluded any use of HTTP GET (or
other static references to content), and source + destination become
required when the request comes from a portal (i.e. through a proxy),
but optional otherwise.  The operation is easily identified by the
<search> or <status> tags.  Source and destination are definitely useful
when the request is arriving through a portal.  So I guess the options
are:

1. use a <header> structure to contain the information
Easily extensible to include more information, but what else do we want
to put in there?

2. insert source + destination somewhere else - perhaps as attributes of
the <request> tag.
Somewhat less extensible than using a header structure, but fine for a
couple of optional elements like source + destination.

3. use HTTP headers to contain the information.
This option will prevent the use of other protocols (smtp for example)
so probably not a good idea.

Both 1 & 2 make sense to me, my preference leans toward #2 because of
the optional nature of the content that we have currently defined for
header and it makes the request a little cleaner.  

At this early stage of things though, it's probably best to keep the
<header> element as a place to stick stuff that hasn't got a good home
yet.  It will be easy to change at a later stage if it really isn't
necessary.

Cheers,
  Dave V.