Subject: [xmpp] 3921bis - headlines to all available resources

From: Kevin Smith <[email-masked]>
Date: Wed, 21 Jul 2010 16:15:01 +0100

5.2.2 says receiving servers SHOULD send headlines to all available
resources. Should that be qualified to only be if it's sent to the
bare JID?

/K

---

From: Kevin Smith <[email-masked]>
Date: Wed, 21 Jul 2010 16:57:04 +0100

> resources. Should that be qualified to only be if it's sent to the

The table in 8.3.4 seems to be inconsistent with this.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 24 Jul 2010 01:31:04 -0600

[Typed while in flight, delivery will be delayed.]

>> resources. Should that be qualified to only be if it's sent to the

Agreed. Changed to:

   o  headline -- The message provides an alert, a notification, or
      other transient information to which no reply is expected (e.g.,
      news headlines, sports updates, near-real-time market data, and
      syndicated content).  Because no reply to the message is expected,
      typically a receiving client will present a message of type
      "headline" in an interface that appropriately differentiates the
      message from standalone messages, chat messages, or groupchat
      messages (e.g., by not providing the recipient with the ability to
      reply).  If the 'to' address is the bare JID, the receiving server
      SHOULD deliver the message to all of the recipient's available
      resources with non-negative presence priority; if the 'to' address
      is a full JID and there is a matching resource, the server MUST
      deliver the message to that resource; otherwise the server MUST
      silently ignore the message (see Section 8).

Do we want to change "SHOULD deliver the message to all..." to "MUST"? I
suppose there might be legitimate reasons why a server would not deliver
to all non-negative resources, although I can't think of one at the moment.

> The table in 8.3.4 seems to be inconsistent with this.

Fixed to be consistent with the proposed text quoted above.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Waqas Hussain <[email-masked]>
Date: Mon, 26 Jul 2010 03:09:00 +0500

> Fixed to be consistent with the proposed text quoted above.

Would we want to return a stanza error for headline messages to
offline JIDs? Possibly the most popular use of headline messages is
currently in PEP. And if PEP events are being sent to offline
resources, a stanza error helps with cleanup.

--
Waqas Hussain

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Jul 2010 08:38:56 +0200

> resources, a stanza error helps with cleanup.

That's worth discussing. I assume that by "headline message to offline
JID" you mean that the 'to' address is a full JID. Returning an error
here would be consistent with the handling of other message types.

What do others think?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Kevin Smith <[email-masked]>
Date: Wed, 28 Jul 2010 18:11:30 +0100

> here would be consistent with the handling of other message types.

It would be consistent - but it's not clear to me that it's a Good
Thing. Headlines are used in lots of situations where you want fire
and forget stuff (or 'fire and don't care' stuff, more probably). In
these situations, it's probably fine that the sending entity never
gets an error.

I can think of a number of uses where you don't want errors to
headlines, so I guess the question to ask is whether anyone knows of
current uses where you *do* need error responses for headlines?

/K

---

From: Jack Moffitt <[email-masked]>
Date: Wed, 28 Jul 2010 12:09:15 -0600

> current uses where you *do* need error responses for headlines?

If you don't send errors, the origin will never know that it should
probably stop sending them.

jack.

---

From: Kevin Smith <[email-masked]>
Date: Wed, 28 Jul 2010 22:31:20 +0100

> probably stop sending them.

Very true. I was thinking of situations where they were transitory or
one-off errors, but you're right: permanent errors mean that the
sender can stop sending.

/K

---

From: Dave Cridland <[email-masked]>
Date: Thu, 29 Jul 2010 17:44:49 +0100

> one-off errors, but you're right: permanent errors mean that the

So headlines are:

1) Broadcast.
2) Never placed into offline storage.
3) Do not emit errors.

 From where I slouch, I see consensus on the first two, and some  
dissent on the last.

I believe that the intent of no-errors was that automated services,  
like PubSub, wouldn't be inundated with errors from offline contacts.

I'm thinking in particular that errors due to PEP events while a user  
is online will, by the rules in place, end up at one or more of the  
user's clients, which seems wrong.

Assuming servers are allowed to detect ids relating to PEP events  
etc, and handle these themselves, I'm happy for headline to produce  
errors if this is the consensus.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Jack Moffitt <[email-masked]>
Date: Thu, 29 Jul 2010 10:49:43 -0600

> I believe that the intent of no-errors was that automated services, like
> PubSub, wouldn't be inundated with errors from offline contacts.

I'm actually fine with hiding the errors as long as it's for offline
resources of a valid JID. We have other specs in place (at least I
remember this being proposed) for presence based subscriptions.

However, I definitely would want to know if a previously good account
is now gone.

jack.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 29 Jul 2010 17:53:38 +0100

> However, I definitely would want to know if a previously good  

Wouldn't the distinction enable a directory harvesting attack?

Dave.