Subject: [TOOLS-DEVELOPMENT] ical server issue

From: Lou Berger <[email-masked]>
Date: Fri, 11 Sep 2015 10:52:20 -0400

So what's the right way to report an issue with ical.ietf.org?

I see an issue with a meeting from yesterday 9/10/15 on
https://ical.ietf.org/public.php/IAOC/calendar and it looks like the
issues is also there for future meetings.

The meeting correctly shows in Thunderbird as occurring at noon ET, but
on google calendar it shows at 10am ET.  Interesting, this has not been
an issue for other calendars, e.g., finance.

Thanks,
Lou

---

From: Glen <[email-masked]>
Date: Fri, 11 Sep 2015 09:52:55 -0700

Hi Lou -

AMS ([email-masked]) would be the correct place to report a problem
with the calendar *server* - for example, if the calendar server were down,
or you couldn't get access, or something like that.

But I confess I have no idea how or where to "report" the problem you're
encountering.

When I view the feed you mention, I see the meeting coded as:

DTEND;TZID=America/New_York:20150910T130000
DTSTART;TZID=America/New_York:20150910T120000

So the calendar server appears to be delivering it correctly, as you point
out.

The question seems to be why Google calendar is misinterpreting the coding
here.

I also use Gogole calendar, and it is also misinterpreting the coding for
me.... but I cannot tell why, nor would I know to whom that should be
reported.

I welcome thoughts on this matter!

Glen
Glen Barney
IT Director
AMS (IETF Secretariat)

On Fri, Sep 11, 2015 at 7:52 AM, Lou Berger <[email-masked]> wrote:

> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development
>

---

From: Glen <[email-masked]>
Date: Fri, 11 Sep 2015 10:00:36 -0700

Here's an interesting data point:

If I download the file at the https://ical.ietf.org/public.php/IAOC/calendar
URL manually, and save it as an ICS file on my desktop, and then I "Import"
that file into Google, the times display correctly.

It is only if I ask Google to "subscribe" to the URL in live-feed mode that
it seems to incorrectly compute the times.

As there is no difference in the data flow or what is pulled (since the
Calendar server sends everything via HTTP in the same way), I wonder if
something in Google's subscription processor is tripping on something
somewhere.

That's not a solution - because you obviously want the live feed - but it
does provide an additional point of validation, if you like, of the data.

Glen

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Sep 2015 13:05:29 -0400

> an issue for other calendars, e.g., finance.

How can it be a problem with the server that two different clients are displaying different results?  I assume the entries are provided by the server in UTC and that the conversion is done by the client.

Russ

---

From: Lou Berger <[email-masked]>
Date: Fri, 11 Sep 2015 13:59:28 -0400

another data point:
https://ical.ietf.org/public.php/IAOC/finance

works fine...

On 9/11/2015 1:00 PM, Glen wrote:
> If I download the file at the
> https://ical.ietf.org/public.php/IAOC/calendar URL manually, and save
> it as an ICS file on my desktop, and then I "Import" that file into
> Google, the times display correctly.
>
> It is only if I ask Google to "subscribe" to the URL in live-feed mode
> that it seems to incorrectly compute the times.

>
> As there is no difference in the data flow or what is pulled (since
> the Calendar server sends everything via HTTP in the same way), I
> wonder if something in Google's subscription processor is tripping on
> something somewhere.
>
> That's not a solution - because you obviously want the live feed - but
> it does provide an additional point of validation, if you like, of the
> data.
>
> Glen
>
>
>
>
>
>
>
> On Fri, Sep 11, 2015 at 9:52 AM, Glen <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Lou -
>
>     AMS ([email-masked] <mailto:[email-masked]>) would be
>     the correct place to report a problem with the calendar *server* -
>     for example, if the calendar server were down, or you couldn't get
>     access, or something like that.
>
>     But I confess I have no idea how or where to "report" the problem
>     you're encountering.
>
>     So the calendar server appears to be delivering it correctly, as
>     you point out.
>
>     The question seems to be why Google calendar is misinterpreting
>     the coding here.
>
>     I also use Gogole calendar, and it is also misinterpreting the
>     coding for me.... but I cannot tell why, nor would I know to whom
>     that should be reported.
>
>     On Fri, Sep 11, 2015 at 7:52 AM, Lou Berger <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         So what's the right way to report an issue with ical.ietf.org
>         <http://ical.ietf.org>?
>
>         [email-masked] <mailto:[email-masked]>

---

From: Lou Berger <[email-masked]>
Date: Fri, 11 Sep 2015 14:03:00 -0400

> How can it be a problem with the server that two different clients are displaying different results?  I assume the entries are provided by the server in UTC and that the conversion is done by the c…

Both calendars use the standard and valid TZID property and VTIMEZONE
component to provide times in local TZ.  One note, it looks like some
versions of outlook required the TZ names to be quoted (which isn't the
standard).  Perhaps there's something related happening...

---

From: Lou Berger <[email-masked]>
Date: Sun, 13 Sep 2015 11:29:37 -0400

Glenn,

Looks like others have seen similar issues and worked with Google to 
resolve, see links below. Given that there will likely be other Google 
users of the ietf ical server it's probably worth running this to ground...

Lou

- https://productforums.google.com/forum/m/#!topic/calendar/GouovR3g4LY. 
Look at the 4/1 response.

- I lost the link, but someone solve the issues by removing any Z (utc) 
based times from the ics

---

From: Glen <[email-masked]>
Date: Mon, 14 Sep 2015 09:15:56 -0700

Hi Lou -

I"m trying to follow this... but in the thread you link to, and the 4/1
response you cite, it seems that Google is talking about the manual import
of ICS files, and saying that it is fixed, which it is.  I can manually
import the ICS file, and the timezones are all correct on my Google
Calendar.   It seems that the problem only occurs with calendar
subscriptions.

In addition, you mention someone removing UTC times from the ICS...  When I
do a survey of the exported ICS, it seems that about half the times are in
UTC format (e.g. DTSTART:20131219T150000Z), and the other roughly half
appear to have time zone specifiers.  (e.g.
DTSTART;TZID=America/New_York:20150910T120000).  I do not have any way of
automatically making the calendar server remove all the "Z" times from its
feed, and converting them to some time of local time - that is a function
of each calendar item's creation and time zone settings.

Interestingly, the item in question - the one malfunctioning - is the one I
cited above, and it is *not* a "Z" time, but is in fact a localized
timezone time.  I reviewed the file output, and compared them to 2445/5545,
and the output seems to be exactly compliant.  We also have a
properly-constructed VTIMEZONE stanza for it, and it is, as already cited,
working for all other platforms (including Google's manual import.)

So I'm still in the same place - our server is functioning, and functioning
correctly, and RFC-compliant, and although I can confirm that Google is
mangling this on import, I do not have any connections to Google that would
enable me to "run this down..." much as I, too, would like to see this
solved for their platform.

I am open to any thoughts or suggestions... Do we know anyone at Google who
participates in the IETF that might have some access to work on this, for
example?

Glen

---

From: Lou Berger <[email-masked]>
Date: Tue, 15 Sep 2015 23:35:43 -0400

Well in trying a test with removing Z I found something really interesting:

All works well if the non-https version is used
(http://ical.ietf.org/public.php/IAOC/calendar)

Is there perhaps something odd on the server's time setting (assuming
google is somehow using tls time...)?

Lou

On 9/14/2015 12:15 PM, Glen wrote:
> Hi Lou -
>
> I"m trying to follow this... but in the thread you link to, and the
> 4/1 response you cite, it seems that Google is talking about the
> manual import of ICS files, and saying that it is fixed, which it is. 
> I can manually import the ICS file, and the timezones are all correct
> on my Google Calendar.   It seems that the problem only occurs with
> calendar subscriptions.
>
> In addition, you mention someone removing UTC times from the ICS... 
> When I do a survey of the exported ICS, it seems that about half the
> times are in UTC format (e.g. DTSTART:20131219T150000Z), and the other
> roughly half appear to have time zone specifiers.  (e.g. 
> DTSTART;TZID=America/New_York:20150910T120000).  I do not have any way
> of automatically making the calendar server remove all the "Z" times
> from its feed, and converting them to some time of local time - that
> is a function of each calendar item's creation and time zone settings.
>
> Interestingly, the item in question - the one malfunctioning - is the
> one I cited above, and it is *not* a "Z" time, but is in fact a
> localized timezone time.  I reviewed the file output, and compared
> them to 2445/5545, and the output seems to be exactly compliant.  We
> also have a properly-constructed VTIMEZONE stanza for it, and it is,
> as already cited, working for all other platforms (including Google's
> manual import.)
>
> So I'm still in the same place - our server is functioning, and
> functioning correctly, and RFC-compliant, and although I can confirm
> that Google is mangling this on import, I do not have any connections
> to Google that would enable me to "run this down..." much as I, too,
> would like to see this solved for their platform.
>
> I am open to any thoughts or suggestions... Do we know anyone at
> Google who participates in the IETF that might have some access to
> work on this, for example?
>
> Glen
>
>
> On Sun, Sep 13, 2015 at 8:29 AM, Lou Berger <[email-masked]
>     Looks like others have seen similar issues and worked with Google
>     to resolve, see links below. Given that there will likely be other
>     Google users of the ietf ical server it's probably worth running
>     this to ground...
>
>     Lou
>
>     -
>     https://productforums.google.com/forum/m/#!topic/calendar/GouovR3g4LY
>     <https://productforums.google.com/forum/m/#%21topic/calendar/GouovR3g4LY>.
>     - I lost the link, but someone solve the issues by removing any Z
>     (utc) based times from the ics
>
>
>
>
>     On September 11, 2015 2:00:09 PM Lou Berger <[email-masked]
>             <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                 Hi Lou -
>
>                 AMS ([email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>) would be
>                 On Fri, Sep 11, 2015 at 7:52 AM, Lou Berger
>             <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>
>             wrote:
>
>                     So what's the right way to report an issue with
>             ical.ietf.org <http://ical.ietf.org>
>                     <http://ical.ietf.org>?
>
>                     https://ical.ietf.org/public.php/IAOC/calendar and
>             it looks
>                     like the
>                     The meeting correctly shows in Thunderbird as
>             occurring at
>                     noon ET, but
>                     on google calendar it shows at 10am ET. 
>             Interesting, this has
>                     not been
>             <mailto:[email-masked]>
>             <mailto:[email-masked]
>             <mailto:[email-masked]>>
>

---

From: Glen <[email-masked]>
Date: Wed, 16 Sep 2015 09:30:33 -0700

Hi Lou -

Not that I'm aware of....

ietfa:~ # date
Wed Sep 16 09:28:34 PDT 2015
ietfa:~ # sntp -s pool.ntp.org
16 Sep 09:28:36 sntp[15416]: Started sntp
2015-09-16 09:28:38.235822 (+0800) -0.00297 +/- 0.028366 secs
2015-09-16 09:28:38.234173 (+0800) +0.005258 +/- 0.003143 secs
2015-09-16 09:28:38.241367 (+0800) +0.000079 +/- 0.025818 secs
ietfa:~ # date
Wed Sep 16 09:28:39 PDT 2015

We check the clocks as part of our weekly maintenance, and ensure they are
synced to the global time servers.  The above was a manual resync I ran
just now - we seem to be on point there.

Interesting find about the https:// though...

Glen

On Tue, Sep 15, 2015 at 8:35 PM, Lou Berger <[email-masked]> wrote:

> >     <
> https://productforums.google.com/forum/m/#%21topic/calendar/GouovR3g4LY>.

---

From: Lou Berger <[email-masked]>
Date: Wed, 16 Sep 2015 12:40:20 -0400

On 9/16/2015 12:30 PM, Glen wrote:
> ...
..

Given the work around, I'm going to move on to other things.  As we
scale out ical services, and more google users show up, we'll need to
address this.  Certainly publishing the http version as 1st choice for
public calendars will avoid most of this.

Thanks,
Lou

---

From: Glen <[email-masked]>
Date: Wed, 16 Sep 2015 09:43:09 -0700

Understood.  I'll make sure everyone here knows this, and if we locate any
web pages with the less-desirable link, I'll make sure they get updated.

Thanks,
Glen

---

From: Benson Schliesser <[email-masked]>
Date: Wed, 16 Sep 2015 13:06:05 -0400

Just a shot in the dark:  Given that this issue presents itself when Google
Calendar pulls ical info via HTTPS, it occurs to me that perhaps the issue
is with timezone info in the server's certificate..?
-B

---

From: Glen <[email-masked]>
Date: Wed, 16 Sep 2015 10:14:36 -0700

Hi Benson -

The iCal server is using the same global wildcard certificate that the rest
of the IETF services are using.

I just reviewed it, and the time zone information appears to be correctly
set.   The expiration date, for example, is:

8/11/2016 16:12:50 PM (8/11/2016 23:12:50 PM GMT)

Which seems to be more-or-less correct....

Apologies if I'm missing something or looking in the wrong place?

Glen

On Wed, Sep 16, 2015 at 10:06 AM, Benson Schliesser <[email-masked]>
wrote:

> Just a shot in the dark:  Given that this issue presents itself when
> Google Calendar pulls ical info via HTTPS, it occurs to me that perhaps the
> issue is with timezone info in the server's certificate..?
> -B
>
>
>> Understood.  I'll make sure everyone here knows this, and if we locate
>> any web pages with the less-desirable link, I'll make sure they get updated.
>>
>> Thanks,
>> Glen
>>
>>

---

From: Benson Schliesser <[email-masked]>
Date: Wed, 16 Sep 2015 13:51:50 -0400

No, I think my "shot in the dark" was just a miss... I just spent a few
minutes just now looking at the cert, http headers, etc, and it all seems
correct to me. Sorry.
-B

On Wed, Sep 16, 2015 at 1:14 PM, Glen <[email-masked]> wrote:

> Hi Benson -
>
> The iCal server is using the same global wildcard certificate that the
> rest of the IETF services are using.
>
> On Wed, Sep 16, 2015 at 10:06 AM, Benson Schliesser <[email-masked]
> > wrote:
>

---

From: Lou Berger <[email-masked]>
Date: Wed, 16 Sep 2015 14:03:48 -0400

I think ssl includes a time exchange, but I'm certainly not informed
(let alone an expert) on this topic...

On 09/16/2015 01:51 PM, Benson Schliesser wrote:
> minutes just now looking at the cert, http headers, etc, and it all
> seems correct to me. Sorry.
> -B
> 
> 
> On Wed, Sep 16, 2015 at 1:14 PM, Glen <[email-masked]
>     The iCal server is using the same global wildcard certificate that
>     the rest of the IETF services are using.
> 
>     I just reviewed it, and the time zone information appears to be
>     correctly set.   The expiration date, for example, is:
> 
>     On Wed, Sep 16, 2015 at 10:06 AM, Benson Schliesser
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Just a shot in the dark:  Given that this issue presents itself
>         when Google Calendar pulls ical info via HTTPS, it occurs to me
>         that perhaps the issue is with timezone info in the server's
>         certificate..? 
>         -B
> 
> 
>         On Wed, Sep 16, 2015 at 12:43 PM, Glen <[email-masked]
>             Understood.  I'll make sure everyone here knows this, and if
>             we locate any web pages with the less-desirable link, I'll
>             make sure they get updated.
> 
>             Thanks,
>             Glen
> 
> 
>             On Wed, Sep 16, 2015 at 9:40 AM, Lou Berger
>             <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>

---

From: Glen <[email-masked]>
Date: Wed, 16 Sep 2015 11:14:32 -0700

No, no!  Don't apologize!  I am, and we all are, grateful for any insights
or possibilities when we work on *any* problem.  All good, seriously.  I do
the best I can, but I'm always open for help!

Glen

On Wed, Sep 16, 2015 at 10:51 AM, Benson Schliesser <[email-masked]>
wrote:

>> On Wed, Sep 16, 2015 at 10:06 AM, Benson Schliesser <
>> [email-masked]> wrote:
>>

---

From: Glen <[email-masked]>
Date: Wed, 16 Sep 2015 11:16:35 -0700

Nor am I, not to that level, although our clock is correct, and even if it
were not, it would seem to me that Google ignoring the clear directives in
the iCal file transmission, in favor of an incorrect SSL time exchange (and
that again for only *some* of the events in the file) seems undesirable
behavior on their part.

Lou - I did notify the secretariat team about this, just to close on that
part.

Glen

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Sep 2015 15:13:47 -0400

Lou:

Time is part of the TLS handshake nonce.  But, no one checks it.  In fact, in TLS 1.3 it is being replaced with random bits.

Russ