Subject: RE: [BXXPwg] Redirect Feature for BEEP (continued...)

From: "Bob Wyman" <[email-masked]>
Date: Mon, 2 Jul 2001 18:36:32 -0400

Roy Fielding wrote:
>this kind of feature doesn't need to be in BEEP core.
	I've proposed these things as BEEP "features" that would be
registered and specified separately from the core. (see: RFC3080 section
5.2)

> This is what IP load balancers are for -- waiting until 
> the beep session has been established means it has 
> already taken on the load.
	Load balancers work at the wrong level of granularity for some
BEEP related needs...
	As far as I know, there are no existing IP load balancers that
could be used to handle the case where one wishes to redirect traffic
for some, but not all, of the profiles served by a BEEP server. This is
because you can't know which profile the client wants to run until
*after* the BEEP session has been established. This is unlike the HTTP
case where the URL typically shows the load balancer all it needs to
know before a connection to the server is established. 
	To use a load balancer with BEEP would seem to imply that you
would have to have two or more servers with identical profiles. You
would also have to ensure that the applications were designed so that
they could be accessed from multiple machines simultaneously (i.e. the
different instances of the applications might have to share state --
such as user lists, activity data, charging data, etc.) These
restrictions will not always be reasonable due to problems such as
license restrictions on application deployment, increased application
complexity, etc.

> Application redirects need to be handled after the profile 
> is established (because there may be many different types 
> of redirect, like in HTTP).
	The redirection and availability features I'm proposing would
come into play before the application has begun to service the
connection since they are statements made about the BEEP server's
willingness or ability to support the profile. They are not statements
made by the application. The protocols defined in profiles would, of
course, be free to define whatever profile specific redirection or
availability options that they wanted to. 
	Just as the BEEP server is able to publish the list of profiles
that it is willing to support, the server should be able to qualify that
willingness (with availability information) or elaborate on it's
unwillingness (with redirects). The BEEP server should also be able to
respond to a "start" by saying: "I won't start it for you -- go
somewhere else." I read "start" as being a service of the BEEP server --
not of the application that is defined by the profile.

>> So, whenever someone attempts to connect to the wrong
>> machine, they would be redirected to the machine that they belong on.
>> The company could then post the address of only one Beep server and
then
>> let the permanent redirects sort people out as they arrive.
>    This is an application-level redirect -- it belongs in the 
>    profile protocol.
	In many implementations the beep server will control access to
the various profile protocols. Having the application do the redirect
with such servers wouldn't work -- access would be denied before the
application had a chance to provide the redirect information. It seems
to me that the code which denies access should be able to provide the
information needed to recover from the denial.
	It should not be surprising to suggest that the beep server
would take user-specific action based on authentication -- without
invoking a specific profile. This has been suggested a number of times
in the past. For instance the PDM Internet Draft states: 
       "Accordingly, implementations may wish to advertise only 
        tuning profiles used for privacy in their initial greeting 
        (c.f., Section 3 of [BEEP]), and then advertise the BEEP 
        profile for PDM after a tuning restart." 
	Here, it is the BEEP server that decides who can see which
profile -- it is not left to the application to deny access. I suggest
that the server should be able to not only deny access, but also state
when or where access to the profile might be granted. 

		bob wyman

_______________________________________________
BXXPwg mailing list
[email-masked]
http://lists.invisible.net/mailman/listinfo/bxxpwg

---

From: Bill Mills <[email-masked]>
Date: Tue, 3 Jul 2001 00:03:35 -0700

An important issue in 3 below would be proxied authentication/
distributed trust issues.  Non-trivial.

Probably better if you have this requirement to fail their authentication 
and make them use the right server.

-bill

-----Original Message-----
From: Bob Wyman [mailto:[email-masked]]
Sent: Monday, July 02, 2001 9:49 AM
To: [email-masked]
Subject: RE: [BXXPwg] Redirect Feature for BEEP (continued...)

Marshall Rose wrote:
>could you give me an example or two as to 
> how this would be used in practice.

Use cases:

<snip>

3. A company has two Beep servers that each support the same profile,
however, because of quality of service requirements one group of users
is required to use one of the servers while a second group uses a
different server. So, whenever someone attempts to connect to the wrong
machine, they would be redirected to the machine that they belong on.
The company could then post the address of only one Beep server and then
let the permanent redirects sort people out as they arrive.

<snip>

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 3 Jul 2001 10:42:23 -0400

> distributed trust issues.  Non-trivial.
	A redirect would not raise authentication issues since it is
simply advisory information provided by a server. A redirect issued by
one server would not do anything to modify the authentication or
authorization issues on some other server. It is simply a statement that
"I won't serve you here. Try this other machine."
	Thus, as you suggest, someone who receives a redirect as a
result of a start would "fail their authentication" then be advised of
the "right server" to use.

		bob wyman