[OpenSER-Devel] [ openser-Bugs-1788975 ] NOTIFY body absent

[SourceForge.net]

Bugs item #1788975, was opened at 2007-09-05 20:49
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1788975&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver devel
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: NOTIFY body absent 

Initial Comment:
Good afternoon! I have noticed something slightly odd about the presence module's handling of initial NOTIFY messages. 

Assume that user A has a subscription to user B. User B is offline. 

User A signs in. The initial notification message to user A regarding the status of user B does not have a body. This causes a problem in the Pidgin IM client. This client specifically relies on a valid body in the NOTIFY message before sending a 200OK response to OpenSER. If OpenSER does not receive that 200OK response, it cancels the subscription. Therefore, when user B signs on later, user A is not appropriately notified.

I have modified the Pidgin client to account for this misunderstanding. However, the Pidgin developers will not accept that change until the problem is rectified in the OpenSER code. It is their belief that the spec requires a body to ALL notification messages, no matter if the user is available or not. 

To see their comments, you can view the Pidgin ticket at this location:
http://developer.pidgin.im/ticket/2181

Please feel free to contact me at Will.Hawkins at itt.com to discuss this matter further. Thanks for your help!

----------------------------------------------------------------------

Comment By: Daniel Atallah (datallah)
Date: 2007-09-05 22:14

Message:
Logged In: YES 
user_id=325843
Originator: NO

I'd like to clarify as there appears to be some misunderstanding; it isn't
that we (Pidgin) wont accept the proposed change as such, it is that I
didn't find any conclusive documentation to tell whether this was correct
behavior or not, and didn't want to make the change unless we knew it was
correct.

We don't have an active maintainer of our SIMPLE protocol (any takers? ;)
), and the information that I was able to find in
"draft-ietf-simple-partial-notify-09" was inconclusive, so this gives us
the info that we need.

Thanks.

----------------------------------------------------------------------

Comment By: Klaus Darilion (klaus_darilion)
Date: 2007-09-05 21:19

Message:
Logged In: YES 
user_id=1318360
Originator: NO

Uups, amr42 was faster :-)
nevertheless I found something in RFC 3265: 

3.1.6.2. Confirmation of Subscription Creation/Refreshing

   Upon successfully accepting or refreshing a subscription, notifiers
   MUST send a NOTIFY message immediately to communicate the current
   resource state to the subscriber.  This NOTIFY message is sent on the
   same dialog as created by the SUBSCRIBE response.  If the resource
   has no meaningful state at the time that the SUBSCRIBE message is
   processed, this NOTIFY message MAY contain an empty or neutral body.
   See section 3.2.2. for further details on NOTIFY message generation.


----------------------------------------------------------------------

Comment By: Aron Rosenberg (amr42)
Date: 2007-09-05 21:16

Message:
Logged In: YES 
user_id=43318
Originator: NO

NOTIFY requests do NOT have to contain a body per RFC 3265 and RFC 3856
section 6.7 - Only if the Presence Server has knowledge of a proper
presence document might it return that document as a NOTIFY body in a
message.

An empty NOTIFY means that the subscription state is being updated and the
presence server does NOT know anything specific about the presentity state
of that user.

RFC 3856 Section 6.7  "The NOTIFY request MAY contain a body indicating
the state of the presentity."

Pidgin is doing the wrong thing.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1788975&group_id=139143