[Ietf-not43] oss implementation release

[Ted Hardie]

Leslie writes
> >Ted writes:
> > 4.2 Referrals
> > 
> >    To distribute queries for search continuations and to issue entity
> >    references, the service MUST provide a referral mechanism.
> > 
> > 4.3 Common Referral Mechanism
> > 
> >    To distribute queries for search continuation and to issue entity
> >    refences, the service MUST define a common referral scheme and
> >    syntax.
> > 
> > I assume that defining a common referral scheme and syntax is part of
> > the protocol work on our plate.  Are you proposing we strike these
> > requirements?
> 
> Any protocol that meets the requirements must have the
> ability to support some form of a common referral scheme and
> syntax.
> 
> At issue is the *semantics*.  When does a server generate
> a referral?

The question of when a server generates a referral is not what I would
normally call semantics, but I think I see your point.  Let me stretch
it a bit:

1) When *may* a server generate a referral?

2) When *must* a server generate a referral?

3) When *must* a server *not* generate a referral?

My quick view of the answers:

1) Any time it is not an authoritative source 
   for the information requested and it knows
   of other CRISP servers.  (Better if it knows
   something about what they know, of course,
   and the more it knows the better it is).

2) Never.  It should always be possible to configure a server
   to act as a standalone server.

3) When it is an authoritative source for the the
   information.

Of course, the interesting question is "When *should* a server generate
a referral?", but the answer is a boring "it depends" (on the service
mesh(es) the server participates in).

None of this seems to me to change the requirement to specify
a mechanism for referrals when they occur.


					Ted