Re: coments on draft-ietf-sacred-protocol-bss-00

[Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>]

Stephen,

On Wed, 12 Dec 2001, Stephen Farrell wrote:

[...]
> > Section 2.2: authorization identity must equal authentication
> > identity.
> > Why is there this restriction?  A client should be able to attempt to
> > authorize as some other user; it's a server's site policy that
> > determines
> > whether or not this is allowed.  The easiest site policy is to always
> > disallow proxying.
>
> It seemed simpler. Is there really a need for separate identities
> for sacred? I wouldn't have thought so.

To me, it seems un-necessary to have this constraint. Clients that do
not wish to make use of it, or servers that don't want to honor it are
still free to do so. In short, I support Lawrence's suggestion.  This
is also the approach we took in our recent posting.

[...]
> > Section 2.3: why only one operation per connection?
>
> Simplicity.
>
> > I suggest instead that
> > clients MUST be prepared to deal with servers that close the
> > connection
> > after a single operation and servers SHOULD support multiple commands
> > per
> > connection.  To simplify, you might want to say that commands MUST NOT
> > be
> > pipelined; the result of a previous command must be received before
> > the next command can be sent.
>
> Sounds hard to do, for little benefit. How often will multiple sacred
> operations be needed?

Actually, this may be a no-op depending on the degree that the
suggestions made by me and Gareth are accepted; in our proposal, there
would be a persistent connection until it explicitly is closed. And
commands would not be allowed to be pipelined, as Lawrence suggests.
Speaking of that proposal, Gareth and I will try to highlight
suggestions we have (apart from the already discussed BEEP and SASL
issue) in a separate thread, since we feel they haven't received much
attention yet.

[...]

-- Magnus