Kevin Smith wrote:
Per the RFC3921 (including the newer draft), when <message type> is
"normal", presumably appropriate for something like an email, it is
stated that "A receiving client SHOULD present the message in an
interface enabling the recipient to reply, but without a conversation
history."> Although SHOULD != MUST, it's probably not correct to use normative
language (MUST, SHOULD, MAY) with regard to UI recommendations like
these, so I'll clean that up in the next version of rfc3921bis.
I think the intention is that the client should provide a UI for
messages that allows replies to be constructed and with large message
bodies, while chat UI should be presented with the conversation
history.
Sure... Then I'd suggest the aspect about potentially large message
bodies be spelled out instead (and/or a likely corollary to this, a less
immediate expectation of a response).
To change topic slightly...
Since having a @type on <message> is recommended and as the other types
don't seem to apply, should Pubsub recommend use of <message
type=headline> for all of its messages? If so (as really seems necessary
if one type is to be chosen since the closest type, 'normal' seems
excludable since there is no expectation of a reply in Pubsub), might
the following description of the type 'headline' need to be adjusted:
"message is probably generated by an *automated* service that delivers
or broadcasts content (news, sports, market information, RSS feeds,
etc.)" (emph. added)?
'Automated' to me seems to be implying that the service is taken from
some other source and does not involve a conscious update by a
publisher. I know there is a "probably" in there, but that would seem to
me to be overemphasizing, especially if Pubsub (which of course allows
manual publishing of new items rather than a mere aggregration and
(re)distribution of news) is made to use this type.
Brett
