From nobody Sun Jan 15 16:08:10 2017 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C181289B0; Sun, 15 Jan 2017 16:08:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148452528946.3189.11207489811474436942.idtracker@ietfa.amsl.com> Date: Sun, 15 Jan 2017 16:08:09 -0800 Archived-At: Cc: calext-chairs@ietf.org, calsify@ietf.org, aamelnikov@fastmail.fm Subject: [calsify] calext - Not having a session at IETF 98 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 00:08:09 -0000 Daniel Migault, a chair of the calext working group, indicated that the calext working group does not plan to hold a session at IETF 98. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Tue Jan 17 06:27:17 2017 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2CB129406 for ; Tue, 17 Jan 2017 06:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l82QZGe-Cisg for ; Tue, 17 Jan 2017 06:27:14 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705EA1293EE for ; Tue, 17 Jan 2017 06:27:14 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-02v.sys.comcast.net with SMTP id TUidcpajh9XRkTUjBcGRy5; Tue, 17 Jan 2017 14:27:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484663233; bh=PWP5uDd9yfNPqFU4+GJSOgFHohuYotIgUW+ZykV180s=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=ixOUzviHlLHvJ0YGPhyDXaFAqDh/RUWVSYYxLUb6lBbu7KXJn88IKMH0j62Adh+Il bizT0EixTpVGtDpzq2UQ/fP5wA7WUcWN7r49HR5Z8HH6n4MWCjhIlLgJQKiGfrzLQT hHumvVmvSAHvYYYHecQc8ostOEPBvROsSObqm6RfHSWyZzGlOHNYSFl9B+H2FwZ+Tl Q84JJuLuGrZWfHdvYo3QT+zyw1KWi50jLHX9UAuFwF38aE6eE4pMRm57SFyDGvtLcu V2O1vRQUEiUIniqOWPrLNzgngn1RvcLCWifh0ZNAwkKQjGAxYpQLZphox1p08B2k2r bwXNY3hj7eilQ== Received: from THARE ([73.42.15.222]) by resomta-ch2-08v.sys.comcast.net with SMTP id TUjAcZzhJaYRCTUjBcwPNK; Tue, 17 Jan 2017 14:27:13 +0000 From: "Tim Hare" To: Date: Tue, 17 Jan 2017 09:27:11 -0500 Message-ID: <004301d270cd$caed94a0$60c8bde0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdJwzE1kwjwPXolqSDeb5VsWuwsoKw== Content-Language: en-us X-CMAE-Envelope: MS4wfJf6FJaXYZLd8SJovmW4f92TpT2uq28Gd5XT5SHHsvHd98oKqmTd1YxNpwi22/bUu79RdqkZMKiszlE89dRmk7J6vRv8DcDl9kV5ZV6KvgWXNNLl3boH R4LOu5sCXqiEn4UNSiJtRHoCd4q0PlNXS70= Archived-At: Subject: [calsify] Timezone question X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 14:27:15 -0000 This is more of a usage question, probably, but this has come up due to travel, and I thought I'd ask the experts. Let's say Bob lives in the America/New York timezone; travels to Australia (crossing the International Date Line); and while in Australia needs to set an appointment in Los Angeles. There are three timezones to worry about when creating an event - the home timezone of the device, the timezone the devices is in _now_ (usually set due to location services), and the timezone of the event, correct? So, when creating an event, Bob should always: 1. Ensure that timezone support is turned on in the device 2. Set the timezone of an event when creating the event The timezone of where the device _is_ shouldn't matter, if you are following those two rules? If creating a VEVENT in software, then the timezone should always be set, correct? I used to think leaving the timezone off was a solution - but then the software on devices started assuming the timezone of an appointment without one, and that didn't always work well. Thanks Tim Hare Interested Bystander, Non-Inc. From nobody Tue Jan 17 14:11:52 2017 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90C21294C5 for ; Tue, 17 Jan 2017 14:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBubvQ_Vxfk7 for ; Tue, 17 Jan 2017 14:11:49 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.157.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B8A1294A1 for ; Tue, 17 Jan 2017 14:11:49 -0800 (PST) Received: from [172.31.24.61] (VPN-172-31-24-61.VPN.CMU.LOCAL [172.31.24.61]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.15.2/8.15.2) with ESMTPSA id v0HMBk98045672 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Jan 2017 17:11:47 -0500 From: Ken Murchison To: Calsify Organization: Carnegie Mellon University Message-ID: Date: Tue, 17 Jan 2017 17:11:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.1.17.220016 X-SMTP-Spam-Clean: 8% ( HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1300_1399 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, LEGITIMATE_SIGNS 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __CC_NAME 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MOZILLA_USER_AGENT 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0) X-SMTP-Spam-Score: 8% X-Scanned-By: MIMEDefang 2.78 on 128.2.157.37 Archived-At: Subject: [calsify] Review of draft-ietf-calext-ical-relations-00 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 22:11:51 -0000 Overall, this document looks good. Comments below. - There are several instances of "Icalendar", which should be changed to "iCalendar" - Since we update the RELATED-TO property, the boilerplate should state that this document updates RFC 5545 - Sec 1.1, last para, last sent: "These changes allows ..." -> "These changes allow ..." - Sec 1.4, last para: Should the discussion of ATTACH handling reference draft-ietf-calext-caldav-attachments? - Sec 4, para 1, last sent: "... a link to an component ..." -> "... a link to a component ..." - Sec 4, Description, para 2: "It defines ..." -> "This parameter defines ..." - Sec, 7: For the new non-TEXT properties, should we explicitly state that there is NO default value type to force producers to always include VALUE= so that consumers not familiar with the property don't assume an incorrect type? - Sec 7.1, Description, last sent: presumably the Bedework reference needs to be changes to something else - Sec 7.2: Value type is listed as URI, TEXT, or REFERENCE, but the definition only shows URI and REFERENCE - Sec 8.1: Value type UID appears to be missing - Sec 10.2: I don't think STRUCTURED-CATEGORY belongs. Its not a parameter. - Sec 10.4: I don't think REL belongs -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Wed Jan 25 19:32:07 2017 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76444129430 for ; Wed, 25 Jan 2017 19:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf2kXW_7D0XL for ; Wed, 25 Jan 2017 19:32:05 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC40712944F for ; Wed, 25 Jan 2017 19:32:04 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id k15so54137227qtg.3 for ; Wed, 25 Jan 2017 19:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=6qWDCBWYQCGLTw1w2zOXc7m24aIL5g/tTb2CZP4rp1I=; b=MqhOPRcy9hsgtiN9TLLMbY16d499UANNLeBwuKuLQg25JoLfWoqeJjSVNmk5HO44SB GJGb9upfWvsqQZxl0rRoodPQ4PL0bphUceGzae0TzlIly8fLD8h0tAI8PA7aWg9eLeOF ZxRbrAHRTEsztywf5pyPeHa1Llbn0D8lZOKNwqliougjNs25WDjHgoJGN3Qb8KfiIr8V FO7Ba0GytW7BxVqJkLXRgEosUnK1zBsd8+GtZcks3jfn56rP+d55QEDfkk2FxPSumdPO nyNGbHIT3frzkanf6w5ooxcKg/MQbtooEFXMoS0ChyZq3h5VQ9LWbVJk7LDHTDYH0PKn c6bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=6qWDCBWYQCGLTw1w2zOXc7m24aIL5g/tTb2CZP4rp1I=; b=ZrsS0vazh8ZKsst7exYFCw913ZUEN2E5TRX6XeNyirruB3OvV5n1y33zuAr8qKoPaC V3IuK+VMUdXqv6Eh7URwNvbdvdi05BdRCHazLPZNGKsztaVLR2/0ZnR74FcniORnwdTS w5cd9BZhYjmcQtu9r/gtV9uO1PRGUuQNOGe9X3dZTUICg+SuHLDCZGy7kW0DxkItc6Em a6mD+CgRi+f8eOKETH0t9JQZBOaLCb0/LyA1di19kRzMRqaQFr0bb9UFjm4dAoBYm4jV DMUjAYGKuAPeZKLwqN1L62QwrF2gaECZDVCAPhk7kf0YtRXAhaPDilkZ3nhg5dvsqLTb yQZw== X-Gm-Message-State: AIkVDXKsip5NeDomhup4hEIVYSNPls1DRBqxahkFbBu0E+8Q9KI2V/RUYKWfhlS9uB7eZg== X-Received: by 10.55.23.78 with SMTP id i75mr617000qkh.212.1485401523898; Wed, 25 Jan 2017 19:32:03 -0800 (PST) Received: from Michaels-MacBook-Pro.local (cpe-67-252-53-251.nycap.res.rr.com. [67.252.53.251]) by smtp.googlemail.com with ESMTPSA id l51sm233897qtb.13.2017.01.25.19.32.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 19:32:03 -0800 (PST) To: calsify@ietf.org References: <004301d270cd$caed94a0$60c8bde0$@comcast.net> From: Michael Douglass Message-ID: <547a9424-f785-6d54-1073-37947ff5b9cd@gmail.com> Date: Wed, 25 Jan 2017 22:32:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <004301d270cd$caed94a0$60c8bde0$@comcast.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] Timezone question X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 03:32:06 -0000 On 1/17/17 09:27, Tim Hare wrote: > This is more of a usage question, probably, but this has come up due to > travel, and I thought I'd ask the experts. > > Let's say Bob lives in the America/New York timezone; travels to Australia > (crossing the International Date Line); and while in Australia needs to set > an appointment in Los Angeles. > > There are three timezones to worry about when creating an event - the home > timezone of the device, the timezone the devices is in _now_ (usually set > due to location services), and the timezone of the event, correct? At least - could be more > > So, when creating an event, Bob should always: > > 1. Ensure that timezone support is turned on in the device > 2. Set the timezone of an event when creating the event > > The timezone of where the device _is_ shouldn't matter, if you are following > those two rules? If creating a VEVENT in software, then the timezone > should always be set, correct? Correct > I used to think leaving the timezone off was a solution - but then the > software on devices started assuming the timezone of an appointment without > one, and that didn't always work well. That's floating time and the specs don't make this clear but floating time has very few valid uses - even though it gets used all the time. Floating time is really to handle the sort of case where you want an event in your calendar that happens at the same time of the day - wherever you are. For example, you might got for a run at 8am - you have your lunch at 12 noon. You could set these as floating time and then they would show up at the correct time - assuming that the appllcation truly knows what the local timezone is. It might work OK on your phone but with shared calendars it's probably going to show up at a number of different times on different calendars. Really what needs to happen is that certain events need to be tied to your physical location - that could be done by nominating your phone as the 'home' device. Works OK until you go for that flight to Australia and forget to take your phone. The same thing is true of meetings. Many - perhaps most of us - now have meetings - social or business - which involve multiple timezones. It would be useful to have the attendees CURRENT timezone reflected in the event. That way it's clear if we are scheduling a call at 3am in the morning for someone. I suspect that what's emerging is that the timezone should be attached to a person or a location and may change over time - sometimes quite rapidly. Then we link certain attributes of the event to other attributes - so an event may have a starting location and an ending location and those 2 timezones matter. The start time is linked to the start location and the end time to the end. (and i hear an argument developing but there needn't be an end time specified - but even if it's calculated from the duration its local value depends on the end timezone. The technology to do most of this already exists - a small spec change could associate timezones with attendees. Each change to an attendees timezone could trigger an iTip update. Probably more work changing the clients... > > Thanks > Tim Hare > Interested Bystander, Non-Inc. > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify