[sip-comm-dev] [PATCH] reject typing notifications in SIP MESSAGE requests


#1

Hi,

One more thing in the SIP MESSAGE processing: At the moment, SC displays
each and every incoming instant message in the message window,
regardless of its content type. This is not convenient, e.g. for SIMPLE
message composition notifications (RFC 3994, MIME-type
application/im-iscomposing+xml) whose xml-content is currently just put
into the message window if the remote client supports this RFC.

As long as SC isn't properly able to generate / display such
notifications by itself, it's probably a good idea to reject messages
like this. The attached patch file adds a test of incoming MESSAGE
requests and rejects all Content Types except for text/*. The 415
(Unsupported Media Type) reply also includes the required Accept header
field containing text/* as acceptable content type.

Cheers,
Ralph Weires

sip-IM-content-type.patch (3.98 KB)

···

###########################################
CONFIDENTIALITY: This e-mail and any attachments are confidential and may also be privileged.
If you are not the designated recipient, please notify the sender immediately by reply e-mail and destroy all copies (digital and paper).
Any unauthorized disclosure, distribution, copying, storage or use of the information contained in this e-mail or any attachments is strictly prohibited and may be unlawful.


#2

Hi again Ralph,

Thanks again for this patch which as always clear and ready to commit :).
The improvement provided by this patch is really interesting and can really enhance the user experience, so, (once again) you're right this might be corrected.

However, I find the way you do it a little bit dirty. It's really not impossible that one day, someone, implement the message composition support for SIP. This guy will probably forget or ignore this new behavior of the IMOpSet (sending a 415 response to the message composition requests). More dangerous, it's also possible that one day another content type is taken in account and you'll have to modify the IM OpSet to let your new request go without responding 415 even if it has nothing related to Instant Messaging.

IMHO, sending 415 responses is the job of the ProtocolService, I'm thinking at something like a list of all supported content types (for all sort of SIP requests as I think that this 415 response also apply outside of the MESSAGE requests scopes) and a "registerContentTypeProcessor" method.
This way, the protocolService is able to automatically answer a 415 response without forwarding the request to any processor.
In fact, I think that we should handle this as we do with 489 / Bad Event response.

WDYT ?

Cheers,
Ben

ralph.weires@hitec.lu a �crit :

···

Hi,

One more thing in the SIP MESSAGE processing: At the moment, SC displays
each and every incoming instant message in the message window,
regardless of its content type. This is not convenient, e.g. for SIMPLE
message composition notifications (RFC 3994, MIME-type
application/im-iscomposing+xml) whose xml-content is currently just put
into the message window if the remote client supports this RFC.

As long as SC isn't properly able to generate / display such
notifications by itself, it's probably a good idea to reject messages
like this. The attached patch file adds a test of incoming MESSAGE
requests and rejects all Content Types except for text/*. The 415
(Unsupported Media Type) reply also includes the required Accept header
field containing text/* as acceptable content type.

Cheers,
Ralph Weires

###########################################
CONFIDENTIALITY: This e-mail and any attachments are confidential and may also be privileged.
If you are not the designated recipient, please notify the sender immediately by reply e-mail and destroy all copies (digital and paper).
Any unauthorized disclosure, distribution, copying, storage or use of the information contained in this e-mail or any attachments is strictly prohibited and may be unlawful.
------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi again Ben,

You're totally right, the way I did the change is indeed not a good way to deal with this. Up to now, I mainly looked into the two classes I sent patches for (SIP IM/Presence), without taking the whole context of how SC generally handles messages too much into account.

I'd say the way you propose to handle this is just the way to do it :slight_smile:

Cheers,
Ralph

···

-----Original Message-----

From: Benoit Pradelle [mailto:ze_real_neo@yahoo.fr]

Sent: Monday, October 15, 2007 7:36 PM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] [PATCH] reject typing notifications in SIP MESSAGE requests

Hi again Ralph,

Thanks again for this patch which as always clear and ready to commit :).
The improvement provided by this patch is really interesting and can really enhance the user experience, so, (once again) you're right this might be corrected.

However, I find the way you do it a little bit dirty. It's really not impossible that one day, someone, implement the message composition support for SIP. This guy will probably forget or ignore this new behavior of the IMOpSet (sending a 415 response to the message composition requests). More dangerous, it's also possible that one day another content type is taken in account and you'll have to modify the IM OpSet to let your new request go without responding 415 even if it has nothing related to Instant Messaging.

IMHO, sending 415 responses is the job of the ProtocolService, I'm thinking at something like a list of all supported content types (for all sort of SIP requests as I think that this 415 response also apply outside of the MESSAGE requests scopes) and a "registerContentTypeProcessor" method.
This way, the protocolService is able to automatically answer a 415 response without forwarding the request to any processor.
In fact, I think that we should handle this as we do with 489 / Bad Event response.

WDYT ?

Cheers,
Ben

ralph.weires@hitec.lu a écrit :

Hi,

One more thing in the SIP MESSAGE processing: At the moment, SC
displays each and every incoming instant message in the message
window, regardless of its content type. This is not convenient, e.g.
for SIMPLE message composition notifications (RFC 3994, MIME-type
application/im-iscomposing+xml) whose xml-content is currently just
put into the message window if the remote client supports this RFC.

As long as SC isn't properly able to generate / display such
notifications by itself, it's probably a good idea to reject messages
like this. The attached patch file adds a test of incoming MESSAGE
requests and rejects all Content Types except for text/*. The 415
(Unsupported Media Type) reply also includes the required Accept
header field containing text/* as acceptable content type.

Cheers,
Ralph Weires

###########################################
CONFIDENTIALITY: This e-mail and any attachments are confidential and may also be privileged.
If you are not the designated recipient, please notify the sender immediately by reply e-mail and destroy all copies (digital and paper).
Any unauthorized disclosure, distribution, copying, storage or use of the information contained in this e-mail or any attachments is strictly prohibited and may be unlawful.
----------------------------------------------------------------------
--

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

###########################################
CONFIDENTIALITY: This e-mail and any attachments are confidential and may also be privileged.
If you are not the designated recipient, please notify the sender immediately by reply e-mail and destroy all copies (digital and paper).
Any unauthorized disclosure, distribution, copying, storage or use of the information contained in this e-mail or any attachments is strictly prohibited and may be unlawful.

###########################################
CONFIDENTIALITY: This e-mail and any attachments are confidential and may also be privileged.
If you are not the designated recipient, please notify the sender immediately by reply e-mail and destroy all copies (digital and paper).
Any unauthorized disclosure, distribution, copying, storage or use of the information contained in this e-mail or any attachments is strictly prohibited and may be unlawful.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hey guys,

I agree with Ben that we need a mechanism for handling unsupported
content types so thanks for bringing the subject up.

I was quite surprised however, to learn about RFC3994. I didn't know
that you could actually do typing notifications with SIMPLE.

This would be really nice to have and I don't think it would be a tough
hack since we already have all the corresponding events and the
necessary UI support.

Anyone interested in writing the code to support this feature?

Cheers
Emil

···

ralph.weires@hitec.lu wrote:

Hi again Ben,

You're totally right, the way I did the change is indeed not a good way to deal with this. Up to now, I mainly looked into the two classes I sent patches for (SIP IM/Presence), without taking the whole context of how SC generally handles messages too much into account.

I'd say the way you propose to handle this is just the way to do it :slight_smile:

Cheers,
Ralph

-----Original Message-----
From: Benoit Pradelle [mailto:ze_real_neo@yahoo.fr]
Sent: Monday, October 15, 2007 7:36 PM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] [PATCH] reject typing notifications in SIP MESSAGE requests

Hi again Ralph,

Thanks again for this patch which as always clear and ready to commit :).
The improvement provided by this patch is really interesting and can really enhance the user experience, so, (once again) you're right this might be corrected.

However, I find the way you do it a little bit dirty. It's really not impossible that one day, someone, implement the message composition support for SIP. This guy will probably forget or ignore this new behavior of the IMOpSet (sending a 415 response to the message composition requests). More dangerous, it's also possible that one day another content type is taken in account and you'll have to modify the IM OpSet to let your new request go without responding 415 even if it has nothing related to Instant Messaging.

IMHO, sending 415 responses is the job of the ProtocolService, I'm thinking at something like a list of all supported content types (for all sort of SIP requests as I think that this 415 response also apply outside of the MESSAGE requests scopes) and a "registerContentTypeProcessor" method.
This way, the protocolService is able to automatically answer a 415 response without forwarding the request to any processor.
In fact, I think that we should handle this as we do with 489 / Bad Event response.

WDYT ?

Cheers,
Ben

ralph.weires@hitec.lu a �crit :

Hi,

One more thing in the SIP MESSAGE processing: At the moment, SC
displays each and every incoming instant message in the message
window, regardless of its content type. This is not convenient, e.g.
for SIMPLE message composition notifications (RFC 3994, MIME-type
application/im-iscomposing+xml) whose xml-content is currently just
put into the message window if the remote client supports this RFC.

As long as SC isn't properly able to generate / display such
notifications by itself, it's probably a good idea to reject messages
like this. The attached patch file adds a test of incoming MESSAGE
requests and rejects all Content Types except for text/*. The 415
(Unsupported Media Type) reply also includes the required Accept
header field containing text/* as acceptable content type.

Cheers,
Ralph Weires

###########################################
CONFIDENTIALITY: This e-mail and any attachments are confidential and may also be privileged.
If you are not the designated recipient, please notify the sender immediately by reply e-mail and destroy all copies (digital and paper).
Any unauthorized disclosure, distribution, copying, storage or use of the information contained in this e-mail or any attachments is strictly prohibited and may be unlawful.
----------------------------------------------------------------------
--

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

###########################################
CONFIDENTIALITY: This e-mail and any attachments are confidential and may also be privileged.
If you are not the designated recipient, please notify the sender immediately by reply e-mail and destroy all copies (digital and paper).
Any unauthorized disclosure, distribution, copying, storage or use of the information contained in this e-mail or any attachments is strictly prohibited and may be unlawful.

###########################################
CONFIDENTIALITY: This e-mail and any attachments are confidential and may also be privileged.
If you are not the designated recipient, please notify the sender immediately by reply e-mail and destroy all copies (digital and paper).
Any unauthorized disclosure, distribution, copying, storage or use of the information contained in this e-mail or any attachments is strictly prohibited and may be unlawful.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net