[BXXPwg] Redirect Feature for BEEP (continued...)

Bob Wyman bobwyman@firstrain.com
Fri, 29 Jun 2001 17:30:57 -0400

Folk will remember that back in January I proposed an HTTP-like
"redirect" feature for BEEP. (see:
http://lists.invisible.net/pipermail/bxxpwg/2001-January/000478.html) At
the time, it was suggested that we wait until after the spec was
published before registering features. The specs have been published...

I'd like to see a "redirect" feature registered. This would result in
greeting replies that look like the following:

    L: RPY 0 0 . 0 142
    L: Content-Type: application/beep+xml
    L: <greeting features='redirect'>
    L:    <profile uri='http://xml.resource.org/profiles/TLS' />
    L: </greeting>
    L: END

After having sent such a greeting, a BEEP peer could then respond to a
start message with and error message something like the following:

      S: ERR 0 1 . 264 127
      S: Content-Type: application/beep+xml
      S: <error code='421'>service not available</error>
      S: <redirect fqdn='foo.bar.com' port='3333' />
      S: END

Such an error message would inform the Peer that issued the start
message that while the channel cannot be started on the target system,
it might succeed if retried on the foo.bar.com system. If the
unavailability of the service on the target system is temporary, the
redirect would be attached to an error message with code 421. If the
unavailability is believed to be permanent, the error code would be 521.

Question #1: What is the best way to designate the endpoint to which one
should redirect?
The "fqdn" and "port" business is necessary since we don't have an URL
for BEEP. I would, however, much prefer being able to say:

	S: <redirect uri='beep://foo.bar.com:3333'/>
	S: <redirect uri='beep.sctp://foo.bar.com' />

However, in the recent "SOAP over BEEP" discussions, it appeared to be
widely held that a URI for BEEP was inappropriate... Does redirect
present a different case?

Question #2: I'd like to save potential round-trips by having the
redirect feature provide for modification of the profile elements
themselves. i.e. not requiring that one wait for a response to a start
element in order to discover that redirection is required.
Would it be reasonable to allow for greetings such as:

    L: <greeting features='redirect'>
    L:    <profile uri='http://example.org/JADE' />
    L:    <profile uri='http://iana.org/beep/apex' 
            redirect='beep://foo.bar.com' />
    L: </greeting>

Such a greeting would tell you that the JADE protocol might be handled
locally, however, if you want "apex," you'll have to try beep at

Question #3: In the case of temporary unavailability of service for a
profile, should the system which issues a redirect be able to provide an
estimate for how long the unavailability will last? For instance, the
presence protocol provides for "availableUntil." Should redirects be
able to state "availableAfter"? i.e.:

     <redirect fqdn='foo.bar.com' port='3333' 
        availableAfter='16 Aug 2001 14:02:00 -0800' />
    <profile uri='http://iana.org/beep/apex' 
        availableAfter='16 Aug 2001 14:02:00 -0800 />

Question #4: If "availableAfter" is reasonable, would it also be
reasonable to allow it to be specified in the absence of a "redirect"
attribute. i.e. For a service which is known to be temporarily down
(probably for maintenance) until some known time but for which no
alternative is known. If "yes" this would allow:

     <redirect availableAfter='16 Aug 2001 14:02:00 -800' />

Thanks for your consideration.

		bob wyman