| New schedule for an Outlook meeting [message #146407] |
Tue, 13 August 2019 10:48  |
amillon
Messages: 1
Registered: August 2019
|
|
|
|
I opened a ticket recently on GFI support and I am asked to post my request on the forum.
Here is the problem :
1. Issue Description:
When we want to propose a new schedule for an Outlook meeting, the meeting organizer does not receive the new schedule. The time that appears in the e-mail it receives the hour of the meeting.
2. Steps to reproduce:
Create an Outlook meeting by inviting one or more people. On the Outlook of a guest, offers a new schedule for this meeting. You will see that the organizer does not see the new schedule and can not validate it.
3. Actual results:
See screenshot "actual results".
We cant validate (or reject) the user's new schedule, as should be done in Outlook.
Here's the answer from the support: The methods COUNTER and DECLINECOUNTER needs to be implemented. However, Kerio connect does not support the COUNTER and DECLINECOUNTER methods.
I would like this request to be taken into account in a new feature.
Thank you in advance.
Best regards.
|
|
|
|
|
|
 Re: New schedule for an Outlook meeting [message #146726 is a reply to message #146407] |
Thu, 03 October 2019 03:01  |
phs
Messages: 1
Registered: October 2019
|
|
|
|
This is acknowledged in support article 360008777839 (forum won't let me post links, even to GFI's own website  )
That article states at the very bottom:
Quote:
The RFC (Request for Comments) indicates that the method's COUNTER, and DECLINECOUNTER needs to be implemented for supporting the Propose New Time feature. However, as per our investigation, it has been discovered that Kerio Connect does not support the COUNTER and DECLINECOUNTER at this point and hence is not able to support this feature of MS Outlook.
In my support ticket regarding this, GFI claim that "I have checked with our experts and as per our developer, this is not a bug and Kerio Connect is compliant with RFC."
Reading the linked RFC 5546, Section 5.1 indicates that partial support of the protocol is acceptable, however the implementation SHOULD fallback to sending a "Not Supported" message in response to a COUNTER or DECLINECOUNTER if they are not implemented. Since Kerio has not currently implemented COUNTER and DECLINECOUNTER support, the client SHOULD be responding with "Not Supported" (Status Code 3.14 refer to section 3.6.27). I believe this makes Kerio not RFC-compliant. Obviously the preferred solution would be to implement the RFC to support the feature (as opposed to sending the "Not Supported" status).
The RFC was published in December 2009; almost 10 years ago. It obsoletes RFC 2446 from November 1998; over 20 years ago. Both RFC's included the COUNTER and DECLINECOUNTER methods. This is by no means a new feature introduced in the RFC, and predates the release of Kerio Connect itself.
This should be treated as a BUG, not a FEATURE REQUEST. I already have to fight off every idiot that thinks Exchange is the only mail server that should ever be used; not being able to use this simple functionality that has existed for over 20 years makes that extremely difficult
|
|
|
|
Members
Search
Help
Register
Login
Home
