This commit is contained in:
Peter Saint-Andre 2013-01-03 19:31:15 -07:00
parent c9e013e889
commit 6bc1dfc72e
1 changed files with 21 additions and 0 deletions

View File

@ -20,6 +20,7 @@
not be provided, and how the meta-data is to be processed.</abstract> &LEGALNOTICE;
<type>Standards Track</type>
@ -48,6 +49,14 @@
<p>Clarify catalogs are temporal objects. Offer client handling suggestions.</p>
@ -289,6 +298,18 @@
directly usable by the client. For instance, the client's server might require a
particular only-locally-known label be used in messages to a particular remote JID.</p>
<p>It is RECOMMENDED the server publish catalogs of security label for use by clients.</p>
<p>Two identical catalog requests may returned different results, even for the same
requester, as the results may depend on numerous factors. It is suggested that clients
request a catalog for use in a short-lived context, such as short-lived 1-to-1 chat
session, for all use in stanzas of that session. For use in long-lived context, such
as a long-lived Multi-User Chat session, it is suggested the client request the
current catalog when the user becomes present after a period of extended absence.
Alternatively, a client could simply cache catalog results for a configurable amount of
time. With either approach, it is also suggested clients provide a means for the user
to request an immediate refresh of all catalogs in all contexts. This is useful where
the user made changes to a personal label catalog which the XMPP server uses as input
in processing catalog requests. Note: there is no requirement that XMPP servers
support 'personal label catalogs' (such details are beyond the scope of this document).</p>
<p>If catalog is restrictive, as indicated by the <tt>restrict=</tt> attribute with value of
true, the client SHOULD restrict the user to choosing one of the items from the catalog
and use the label of that item (or no label if the selected item is empty).</p>