[jdev] service banners?

[Peter Saint-Andre]

Jefferson Ogata wrote:

> Again, the requirement is that this occur before authentication.
> 
> Look at how FTP, ssh2, or rsync do it. Really, it is an oversight that
> this is not currently built in to XMPP; it's trivial to define an
> attribute or element at the beginning of the stream element to handle
> this. It's a matter of specifying that and then having clients present
> it to the user before logging in. The original question was simply
> whether this was in the protocol definition anywhere, and I think Peter
> answered quite clearly right off the top.

The question is not whether certain organizations need this, the
question is how to best do this in XMPP. IMHO we have two alternatives:

1. A new, optional attribute in the stream header. This informs the
receiving party of the service policy but does not require the receiving
party to affirm that they accept the service policy. Plus the client may
not understand the new attribute and thus ignore it. Therefore the
server would never know if the policy has been shown to a user, let
alone whether the user agrees to abide by the policy.

2. A new stream feature. This would involve a request-response model,
wherein the server sends the current policy to the client and the client
MUST show the policy to the human user (if any) and the client MUST
return some kind of ack to the server (yes, I showed it to the human and
the human agreed to abide by the policy). The server could make receipt
of the ACK necessary in order to proceed (a la <required/> for TLS) and
provide only the service banner in the initial stream feature set. Thus
the server could know that a user has seen and agrees to the policy
before allowing the client to proceed with TLS and SASL.

The second option seems preferable to me, especially since it doesn't
require any changes to RFC 3920 (we can define stream features to our
heart's content, e.g. in a JEP). Naturally this is all XMPP 1.0 stuff,
older ("XMPP 0.9") clients might not be able to connect depending on how
much the service admins have locked things down. But I take it that is
the point.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20060719/75ce0b84/attachment-0002.bin>