[jdev] Re: service banners?

[Alexander Gnauck]

solution 2 soubds very good to me. And i agree with jefferson that we 
need smth like banners. At least if you register a new account with a 
service

Alex

Peter Saint-Andre schrieb:
> 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
>