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

From: "Bob Wyman" <[email-masked]>
Date: Wed, 17 Jan 2001 13:55:35 -0800

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

---

From: "Marshall T. Rose" <[email-masked]>
Date: Wed, 17 Jan 2001 20:28:56 -0800

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: [email-masked]
  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

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 17 Jan 2001 21:34:47 -0800

> 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 ; [email-masked] 
  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...

  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: [email-masked] 
    Sent: Wednesday, January 17, 2001 13:55
    Subject: [BXXPwg] Why won't you talk to me? (i.e. 421 - service not available), and redirection...

            bob wyman

---

From: "Marshall T. Rose" <[email-masked]>
Date: Thu, 18 Jan 2001 09:38:00 -0800

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 ; [email-masked]
  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

  > 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

  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 ; [email-masked]
    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

    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: [email-masked]
      Sent: Wednesday, January 17, 2001 13:55
      Subject: [BXXPwg] Why won't you talk to me? (i.e. 421 - service not

      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.

              bob wyman