|
|
I don't understand how your suggested solution handles the case of child
help, where in one jurisdiction, there is an emergency, and in another there
is only an NGO non-emergency. Do you propose to have two entries in the
tree, and populate one or both and have the client know the difference?
I also don't understand the protocol difference between "return a list of
sos.*" and "the second-best answer is a list". Both involve the protocol
returning one or more items in a list.
Brian
> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@xxxxxxxxxxxxxxx]
> Sent: Monday, May 22, 2006 4:29 PM
> To: Ted Hardie
> Cc: ecrit@xxxxxxxx
> Subject: Re: [Ecrit] Related services (was: Summary of recent discussion)
>
> There seem to be two approaches to this problem: client-based and
> server-based.
>
> In a client-based approach, the server returns an error when a
> particular service is unavailable. The client then retries with the more
> general service (sos.police -> sos).
>
> Ted seems to advocate the server-based approach where the server
> "guesses" (quoted, since this might be a fairly predictable algorithm)
> what the user would want in the absence of its first choice.
>
> I don't think there's a right answer here. The client-based approach has
> the advantage of not returning information that the client already had
> ("Thanks, I already know about service:sos since I just asked for it,
> but I wanted to know whether there are sub-services.") and being
> slightly simpler.
>
> The server-based approach has the advantage that the server may have a
> better idea what's available, avoiding having to client to try a bunch
> of things. (The discovery mechanism addresses that problem to some
> extent.)
>
> The problem with the server-based approach is that it starts to get
> messy if the alternative, second-best answer is a list, not a single
> answer. Suddenly, the protocol has to support providing a possibly
> lengthy list of services that are all potential substitutes.
>
> My gut feeling is that modular protocols are easier to get correct,
> where each request does something simple and the client makes decisions.
> For this case, the behavior would be something like
>
> (1) client asks for sos-related services and obtains a list of services
> (some subset of the sub-services in the sos.* list)
>
> (2) client obtains the sub-service information (URLs, description, etc.)
> it cares about
>
> Henning
>
>
> Ted Hardie wrote:
> > A
> >>> Still, I agree that returning the service URN that is associated with
> the responder
> >>> may be appropriate, as there may be cases where that will cause the
> caller to
> >>> make some decision (e.g. drop the call if they were calling in a
> police brutality
> >>> sighting). I think that should not be a protocol error, in other
> words, but I think
> >>> we should be strongly pushing for a BCP of urn:service:sos being a
> populated
> >>> item in the LoST emergency server; it really does help
> interoperability here to
> >>> have a default.
> >> I am confused with this suggestion.
> >>
> >
> > Sorry for the confusion. I am suggesting that it should not be a
> protocol error
> > for the server to return the contact URI + the service URN when that
> service
> > URN differed from the one that was requested. I think the base reason
> for this
> > is the one we identified a long time ago: I ask for sos.fire, but only
> sos is supported;
> > I return the contact URI, and let the client know that the contact URI
> is for
> > sos. We need that to be possible.
> >
> > Returning the contact URI and the service URN for sos.police when there
> is no sos
> > looks like the same protocol mechanism to me. So I think we shouldn't
> try
> > to rule it out at the protocol level, but advocate instead that people
> accomplish
> > the same thing by populating the sos service URN with the same data as
> is
> > present at sos.police. (Given that this is not a protocol mechanism,
> this would
> > be Best Practice at most).
> >
> > I also acknowledge that there will be corner cases where getting a
> service
> > URN different than the one requested may cause the caller to do
> something
> > other than continue the call. I don't thing we ought to be too
> concerned about that,
> > but given the protocol mechanism is there, we should note it may be
> useful
> > in that case as well.
> >
> > I hope that's clearer,
> > regards,
> > Ted
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@xxxxxxxx
> > https://www1.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|