[jdev] service banners?

[Jefferson Ogata]

On 2006-07-19 15:49, Peter Saint-Andre wrote:
> 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
> 
> 2. A new stream feature. This would involve a request-response model,
> 
> 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.

Either would suit my particular purposes, I think. I see the logic of
preferring option 2, although offhand I think it might require a bit
more work to implement both on the client and the server side. In the
lazy case, clients are free to ignore the message and simply send back
the confirming reply automatically. The server has one more state to track.

Thanks for giving it some thought.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service