[BXXPwg] Why won't you talk to me? (i.e. 421 - service not available), and redirection...

Bob Wyman Bob Wyman" <bobwyman@earthlink.net
Wed, 17 Jan 2001 21:34:47 -0800


This is a multi-part message in MIME format.

------=_NextPart_000_040C_01C080CD.50B516B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Marshal Rose wrote:
> 421 is a transient problem
> 521 is a permanent problem
    I was guessing that 521 would be the permanent code, however, the =
core drafts all have the error codes explicitly listed rather than =
providing any explanation for the meaning of the digits. (521 isn't in =
any of the drafts that I've seen) The error code philosophy is discussed =
in the "design" document, however, that isn't the document that might =
become an RFC is it? Would it make sense to include a discussion of =
error code assignment practices in the core document to provide guidance =
for codes that may be defined in the future?

re: redirect on greeting, or start, or both.
    There are arguments for one or the other or both. But, if it has to =
be in just one place, I think it would be best provided on the start =
message.
    Is this the sort of thing that could be added in the meantime as a =
"feature?" If so, I'd really appreciate a sketch of how that would be =
done. The current documentation discusses features but doesn't provide =
an example. Would something like the following be what is intended:

1) Extend the Greeting message to warn that redirects may occur. Thus, =
the following might be sent:
       L: RPY 0 0 . 0 122
       L: Content-Type: application/beep+xml
       L:
       L: <greeting features=3D'x-redirect'>
       L:    <profile uri=3D'http://xml.resource.org/profiles/TLS' />
       L: </greeting>
       L: END
=20
2) Define two error codes (one for permanent, the other for transient =
redirection) and craft responses to start messages that look like:

    S: ERR 0 1 . 264 127
    S: Content-Type: application/beep+xml
    S:
    S: <error code=3D'4??'>redirection required</error>
    S: <x-redirect fqdn=3D'foo.bar.com' port=3D'3333' /x-redirect>
    S: END

Is this how it works? When I declare a feature to be supported, is there =
anyway that I can point to a profile that defines it? If I've added =
error codes, do I register them somewhere? (The feature definition =
template doesn't explicitly provide for error code declaration.)

        bob wyman

  ----- Original Message -----=20
  From: Marshall T. Rose=20
  To: Bob Wyman ; bxxpwg@lists.invisibleworlds.com=20
  Cc: Marshall Rose=20
  Sent: Wednesday, January 17, 2001 8:28 PM
  Subject: Re: [BXXPwg] Why won't you talk to me? (i.e. 421 - service =
not available), and redirection...


  hi. in terms of unavailable messages:

  421 is a transient problem
  521 is a permanent problem

  in terms of redirects:

  i can see arguments for returning a redirect instead of a greeting. i =
can also see arguments for returning a redirect in response to a start. =
i'm more inclined to favor the latter since a peer might offer several =
services, but need to do redirects on only a subset of them. supporting =
either of these approaches requires a change to the protocol. that's not =
fatal, since there's a field in the greeting element that we can use to =
signal extensibility. however, until the beep specs get published, it =
doesn't make much sense to talk about more enhancements...

  /mtr
    ----- Original Message -----=20
    From: Bob Wyman=20
    To: bxxpwg@lists.invisibleworlds.com=20
    Sent: Wednesday, January 17, 2001 13:55
    Subject: [BXXPwg] Why won't you talk to me? (i.e. 421 - service not =
available), and redirection...


    One of the things I find very frustrating with a number of network =
protocols is that when you get the "service not available" message, you =
don't get answers to the questions: "Why not?" and "When will it be =
back?." Few protocols allow you to do much more than simply poll the =
darned server from time to time in the hope that the thing will return =
to life. In many cases, that polling can simply make matters worse, =
since the unavailability of the service may be because too many people =
are trying to access it...

    It would be very useful, I think, if BXXP could expand it's =
"unavailable" error messages to include:
        1) Service permanently unavailable (i.e. Don't ever try again!)
        2) Service temporarily unavailable (i.e. We'll be back)

    This would allow clients to do more rational things in response to =
being rejected. Cases of temporary unavailability include things like =
startup, shutdown, server is overloaded and can't take more connects, =
databases are being reorganized, backups are being performed, etc. These =
are all cases where it would be good to refuse new connections without =
discouraging people from coming back later. Ideally, the protocol would =
support returning an estimated time to availability in the case of a =
temporary shut-out.

    It would also, I think, be very useful to provide for a redirection =
response, very much like that which we find in HTTP. I realize that one =
can buy all sorts of fancy gear to do load balancing for you, and I =
realize that once you've got a connection to a BXXP server and start =
talking a profile, that profile could implement redirection, however, it =
is still likely that in many cases, scalability of the solution is going =
to be enhanced by allowing the BXXP servers themselves to communicate =
the need to redirect. Of course, just as with "unavailable" messages, =
redirection should be either permanent or temporary.

            bob wyman


------=_NextPart_000_040C_01C080CD.50B516B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Marshal Rose wrote:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT size=3D2>&gt; 421 is a transient problem</FONT></DIV>
<DIV><FONT size=3D2>&gt; 521 is a permanent =
problem</FONT></DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; I was guessing that =
521 would be=20
the permanent code, however, the core drafts all have the error codes =
explicitly=20
listed rather than providing any explanation for the meaning of the=20
digits.&nbsp;(521 isn't in any of the drafts that I've seen) The error =
code=20
philosophy is discussed in the "design" document, however, that isn't =
the=20
document that might become an RFC is it? Would it make sense to =
include&nbsp;a=20
discussion of error code assignment practices in the core document to =
provide=20
guidance for codes that may be defined in the future?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>re: redirect on greeting, or start, or=20
both.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; There are arguments =
for one or=20
the other or both. But, if it has to be in just one place, I think it =
would be=20
best provided on the start message.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Is this the sort of =
thing that=20
could be added in the meantime as a "feature?" If so, I'd really =
appreciate a=20
sketch of how that would be done. The current documentation discusses =
features=20
but doesn't provide an example. Would something like the following be =
what is=20
intended:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1) Extend the Greeting message =
to&nbsp;warn that=20
redirects may occur. Thus, the following might be sent:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; L: =
RPY 0 0 . 0=20
122<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; L: Content-Type:=20
application/beep+xml<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
L:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; L: &lt;greeting=20
features=3D'x-redirect'&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
L:&nbsp;&nbsp;&nbsp; &lt;profile =
uri=3D'http://xml.resource.org/profiles/TLS'=20
/&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; L:=20
&lt;/greeting&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; L:=20
END<BR>&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2) Define&nbsp;two error codes (one=20
for&nbsp;permanent, the other for transient redirection)&nbsp;and craft=20
responses to start messages that look like:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
size=3D2></FONT><FONT face=3DArial size=3D2></FONT><BR><FONT =
face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp; S: ERR 0 1 . 264 127<BR>&nbsp;&nbsp;&nbsp; =
S:=20
Content-Type: application/beep+xml<BR>&nbsp;&nbsp;&nbsp;=20
S:<BR>&nbsp;&nbsp;&nbsp; S: &lt;error code=3D'4??'&gt;redirection=20
required&lt;/error&gt;<BR>&nbsp;&nbsp;&nbsp; S: &lt;x-redirect=20
fqdn=3D'foo.bar.com' port=3D'3333' /x-redirect&gt;<BR>&nbsp;&nbsp;&nbsp; =
S:=20
END<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Is this how it works? When I declare a =
feature to=20
be supported, is there anyway that I can point to a profile that defines =
it? If=20
I've added error codes, do I register them somewhere? (The feature =
definition=20
template doesn't explicitly provide for error code =
declaration.)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
bob=20
wyman</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dmrose+mtr.netnews@dbc.mtview.ca.us=20
  href=3D"mailto:mrose+mtr.netnews@dbc.mtview.ca.us">Marshall T. =
Rose</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dbobwyman@earthlink.net=20
  href=3D"mailto:bobwyman@earthlink.net">Bob Wyman</A> ; <A=20
  title=3Dbxxpwg@lists.invisibleworlds.com=20
  =
href=3D"mailto:bxxpwg@lists.invisibleworlds.com">bxxpwg@lists.invisiblewo=
rlds.com</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3Dmrose@dbc.mtview.ca.us=20
  href=3D"mailto:mrose@dbc.mtview.ca.us">Marshall Rose</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, January 17, =
2001 8:28=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [BXXPwg] Why won't =
you talk=20
  to me? (i.e. 421 - service not available), and redirection...</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
  face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
  size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
  size=3D2></FONT><FONT face=3DArial size=3D2></FONT><BR></DIV>
  <DIV><FONT size=3D2>hi. in terms of unavailable messages:</FONT></DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2>421 is a transient problem</FONT></DIV>
  <DIV><FONT size=3D2>521 is a permanent problem</FONT></DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2>in terms of redirects:</FONT></DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2>i can see arguments for returning a redirect =
instead of a=20
  greeting. i can also see arguments for returning a redirect in =
response to a=20
  start. i'm more inclined to favor the latter since a peer might offer =
several=20
  services, but need to do redirects on only a subset of them. =
supporting either=20
  of these approaches requires a change to the protocol. that's not =
fatal, since=20
  there's a field in the greeting element that we can use to signal=20
  extensibility. however, until the beep specs get published, it doesn't =
make=20
  much sense to talk about more enhancements...</FONT></DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2>/mtr</FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=3Dbobwyman@earthlink.net =
href=3D"mailto:bobwyman@earthlink.net">Bob=20
    Wyman</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
    title=3Dbxxpwg@lists.invisibleworlds.com=20
    =
href=3D"mailto:bxxpwg@lists.invisibleworlds.com">bxxpwg@lists.invisiblewo=
rlds.com</A>=20
    </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, January 17, =
2001=20
    13:55</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [BXXPwg] Why won't =
you talk to=20
    me? (i.e. 421 - service not available), and redirection...</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
size=3D2></FONT><BR></DIV>
    <DIV><FONT face=3DArial size=3D2>One of the things I find very =
frustrating with=20
    a number of network protocols is that when you get the "service not=20
    available" message, you don't get answers to the questions: "Why =
not?" and=20
    "When will it be back?." Few protocols allow you to do much more =
than simply=20
    poll the darned server from time to time in the hope that the thing =
will=20
    return to life. In many cases, that polling can simply make matters =
worse,=20
    since the unavailability of the service may be because too many =
people are=20
    trying to access it...</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>It would be very useful, I think, =
if BXXP could=20
    expand it's "unavailable" error messages to include:</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 1) Service =
permanently=20
    unavailable (i.e. Don't ever try again!)</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 2) Service =
temporarily=20
    unavailable (i.e. We'll be back)</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>This would allow clients to do more =
rational=20
    things in response to being rejected.&nbsp;Cases of temporary =
unavailability=20
    include things like&nbsp;startup, shutdown,&nbsp;server is=20
    overloaded&nbsp;and can't take more connects, databases are being=20
    reorganized, backups are being performed, etc. These are all cases =
where it=20
    would be good to refuse new connections without discouraging people =
from=20
    coming back later. Ideally, the protocol would support returning an=20
    estimated time to availability in the case of a temporary=20
    shut-out.</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>It would also, I think, be very =
useful to=20
    provide for a redirection response, very much like that which we =
find in=20
    HTTP. I realize that one can buy all sorts of fancy gear to do load=20
    balancing for you, and I realize that once you've got a connection =
to&nbsp;a=20
    BXXP server and start talking a profile, that profile could =
implement=20
    redirection, however, it is still likely that in many cases, =
scalability of=20
    the solution is going to be enhanced by allowing the BXXP servers =
themselves=20
    to communicate the need to redirect. Of course, just as with =
"unavailable"=20
    messages, redirection should be either permanent or =
temporary.</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bob=20
    wyman</FONT></DIV>
    <DIV><FONT face=3DArial=20
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_040C_01C080CD.50B516B0--