Re: [Standards] message type=normal, message type=headline
Ralph Meijer wrote: On Fri, Oct 10, 2008 at 05:30:26AM +0800, Brett Zamir wrote: [..] 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? As I mentioned in another thread the other day, the publish-subscribe specification does not require RFC 3921, because a large part of it should also work in non-IM contexts. Hence, those message types might not apply and using no message type is the best we can do. Well, if you receive a message with a type you don't understand, you MUST treat it as type='normal', so I think it would be OK to talk about type='headline' in XEP-0060 and certainly XEP-0163 (which does depend on RFC 3921). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] message type=normal, message type=headline
On Fri, Oct 10, 2008 at 05:30:26AM +0800, Brett Zamir wrote: [..] 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? As I mentioned in another thread the other day, the publish-subscribe specification does not require RFC 3921, because a large part of it should also work in non-IM contexts. Hence, those message types might not apply and using no message type is the best we can do. -- Groetjes, ralphm
Re: [Standards] message type=normal, message type=headline
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
Re: [Standards] message type=normal, message type=headline
On Thu Oct 9 22:30:26 2008, Brett Zamir wrote: 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)? The broadcast aspects of a pubsub service are automated - the content is not, and the decision to use those services is not, but then, sports information is not automated either - someone, somewhere, makes the decision to broadcast/publish it. I think these days, the description ought to be updated to include a direct reference to pubsub, actually. RSS should be replaced with Atom, and there's a possible informational reference to Atom-over-PubSub there, too. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
