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

Marshall T. Rose mrose+mtr.netnews@dbc.mtview.ca.us
Thu, 18 Jan 2001 09:38:00 -0800


This is a multi-part message in MIME format.

------=_NextPart_000_0165_01C08132.58D89230
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

look around for some lore called "the theory of reply codes" (e.g., in RFC
821), and you'll see what the three digits mean...

i haven't sat down to design a redirection feature for beep. what you
outline below is probably pretty close to the optimal. however, the problem
probably isn't interesting until the beep specs get published...

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


  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='x-redirect'>
         L:    <profile uri='http://xml.resource.org/profiles/TLS' />
         L: </greeting>
         L: END

  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='4??'>redirection required</error>
      S: <x-redirect fqdn='foo.bar.com' port='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 -----
    From: Marshall T. Rose
    To: Bob Wyman ; bxxpwg@lists.invisibleworlds.com
    Cc: Marshall Rose
    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 -----
      From: Bob Wyman
      To: bxxpwg@lists.invisibleworlds.com
      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_0165_01C08132.58D89230
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.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>look around for some lore called "the theory of =
reply codes"=20
(e.g., in RFC 821), and you'll see what the three digits =
mean...</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>i haven't sat down to design a redirection feature =
for beep.=20
what you outline below is probably pretty close to the optimal. however, =
the=20
problem probably isn't interesting until the beep specs get=20
published...</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=3Dmrose+mtr.netnews@dbc.mtview.ca.us=20
  href=3D"mailto:mrose+mtr.netnews@dbc.mtview.ca.us">Marshall T. =
Rose</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=20
  21:34</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><BR></DIV>
  <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=20
  be the permanent code, however, the core drafts all have the error =
codes=20
  explicitly 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 .=20
  0 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?=20
  If I've added error codes, do I register them somewhere? (The feature=20
  definition template doesn't explicitly provide for error code=20
  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=20
    talk 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=20
    several services, but need to do redirects on only a subset of them. =

    supporting either of these approaches requires a change to the =
protocol.=20
    that's not fatal, since there's a field in the greeting element that =
we can=20
    use to signal extensibility. however, until the beep specs get =
published, it=20
    doesn't make 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=20
      to 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=20
      with 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=20
      simply poll the darned server from time to time in the hope that =
the thing=20
      will return to life. In many cases, that polling can simply make =
matters=20
      worse, since the unavailability of the service may be because too =
many=20
      people are 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=20
      could 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=20
      unavailability 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=20
      it would be good to refuse new connections without discouraging =
people=20
      from 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 BXXP server and start talking a profile, that profile =
could=20
      implement redirection, however, it is still likely that in many =
cases,=20
      scalability of the solution is going to be enhanced by allowing =
the BXXP=20
      servers themselves to communicate the need to redirect. Of course, =
just as=20
      with "unavailable" messages, redirection should be either =
permanent or=20
      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;=20
      bob wyman</FONT></DIV>
      <DIV><FONT face=3DArial=20
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY=
></HTML>

------=_NextPart_000_0165_01C08132.58D89230--