Dave Cridland wrote:
> On Mon Oct 27 17:48:11 2008, Peter Saint-Andre wrote:
>> Dave Cridland wrote:
>> > On Mon Oct 27 17:36:49 2008, Peter Saint-Andre wrote:
>> >> Peter Saint-Andre wrote:
>> >> > Dave Cridland wrote:
>> >> >> On Mon Oct 27 17:24:20 2008, Peter Saint-Andre wrote:
>> >> >>> Dave Cridland wrote:
>> >> >>>> Now, groupchat messages are currently handled as normal/chat. But
>> >> >>> should
>> >> >>>> they be?
>> >> >>> Define "currently"; I made a fix to this text in the last
>> revision of
>> >> >>> rfc3921bis:
>> >> >> Ah, cool, however, this really affects 8.3.1.1, or 8.2.2.
>> >> >
>> >> > Author oversight. Will fix.
>> >>
>> >> Never mind, because 8.2.2 says:
>> >>
>> >> For a message stanza, the server SHOULD treat the stanza as if it were
>> >> addressed to <[EMAIL PROTECTED]> as described in the next section (but
>> without
>> >> modifying the value of the 'to' attribute).
>> >
>> > Yes - either 8.2.2 would need fixing, or else "the next section" it
>> > points to when other resources are available, which is 8.3.1.1, would
>> > need fixing, because it says:
>> >
>> >     For a message stanza of type "chat", "error", "groupchat", or
>> > "normal", the
>> >     server SHOULD deliver the stanza to the highest-priority available
>> > resource.
>> >
>> > 8.3.2.1, the section you've changed already, only affects the case
>> where
>> > no resources for the account are available.
>>
>> Aha, correct. Too many subsections...
>>
>>
> http://svn.xmpp.org:18080/changelog/XMPP/?cs=2444
> 
> That change certainly reflects what I thought ought to happen. Does
> anyone disagree?

The text now reads....

8.3.  Bare JID at Local Domain

   If the hostname of the domain identifier portion of the JID contained
   in the 'to' attribute of an inbound stanza matches one of the
   configured hostnames of the server itself and the JID contained in
   the 'to' attribute is of the form <[EMAIL PROTECTED]>, the server MUST
   adhere to the following rules.

8.3.1.  Available or Connected Resources

   If there is at least one available or connected resource, how the
   stanza is processed depends on the stanza type.

8.3.1.1.  Message

   For a message stanza of type "headline", the server SHOULD deliver
   the stanza to all available resources.

   For a message stanza of type "chat" or "normal", the server SHOULD
   deliver the stanza to the highest-priority available resource.  If
   there is not one highest-priority available resource but instead the
   highest priority is asserted by two or more available resources,
   these resources are said to form a "delivery tie".  In the case of a
   delivery tie, a server SHOULD deliver the message to all of the tied
   resources.  However, before delivering the message, a server MAY
   remove one or more resources from the tie.  Methods for doing so are
   outside the scope of this specification, but could include factors
   such as the resource's time of connection, time of last network or
   application activity, availability as determined by some hierarchy of
   <show/> values, or user-configured rules.  Nevertheless, a server
   MUST NOT remove all resources from the tie, and MUST deliver the
   message to at least one of the highest-priority resources (subject to
   appropriate security policies as described under Section 11 and in
   [XMPP-CORE]).

   For a message stanza of type "groupchat", the server SHOULD NOT
   deliver the stanza to any of the available resources but instead
   SHOULD return an error to the sender.

   For a message stanza of type "error", the server SHOULD silently
   discard the message (i.e., neither deliver it to the intended
   recipient nor return an error to the sender).

   However, for any message type the server MUST NOT deliver the stanza
   to any available resource with a negative priority; if the only
   available resource has a negative priority, the server SHOULD handle
   the message as if there were no available or connected resources as
   described under Section 8.3.2.

   In all cases, the server MUST NOT rewrite the 'to' attribute (i.e.,
   it MUST leave it as <[EMAIL PROTECTED]> rather than change it to
   <[EMAIL PROTECTED]/resource>).

Reply via email to