IETF Logo Mail Archive

Re: [calsify] RFC7986 and EMAIL parameter

Cyrus Daboo <cyrus@daboo.name> Wed, 17 February 2021 16:24 UTC

Return-Path: <cyrus@daboo.name>
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 A97A33A0C2A for <calsify@ietfa.amsl.com>; Wed, 17 Feb 2021 08:24:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 YQ-jTjGnPuuu for <calsify@ietfa.amsl.com>; Wed, 17 Feb 2021 08:24:32 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 694943A0C1E for <calsify@ietf.org>; Wed, 17 Feb 2021 08:24:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 9A89E30449E331; Wed, 17 Feb 2021 11:24:31 -0500 (EST)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLm5UDcixtB8; Wed, 17 Feb 2021 11:24:30 -0500 (EST)
Received: from cyrus.local (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 9D74430449E31F; Wed, 17 Feb 2021 11:24:30 -0500 (EST)
Date: Wed, 17 Feb 2021 11:24:30 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: Michael Douglass <mikeadouglass@gmail.com>, Calsify <calsify@ietf.org>
Message-ID: <0e03fc6b-15ba-43bd-8122-73069886ba61@cyrus.local>
In-Reply-To: <304feeb6-9633-358d-5143-bd5264776c74@gmail.com>
References: <304feeb6-9633-358d-5143-bd5264776c74@gmail.com>
X-Mailer: Mulberry/5.0.0a1 (macOS/10.16)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; size=2870
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/oR-xjAllEFZzeo19Ztk34Z12cFM>
Subject: Re: [calsify] RFC7986 and EMAIL parameter
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Feb 2021 16:24:35 -0000

Hi Michael,

--On Wed, 17 Feb 2021 11:04:41 -0500 Michael Douglass 
<mikeadouglass@gmail.com> wrote:


> Thanks Cyrus.
>
> See below
>
>> As per above, no, it was never intended that EMAIL be used for iMIP.  It
>> is important to note, that some calendar systems allow users to  "sign-
>> up" using a 3rd party email address as their "identifier", but  generate
>> their own mailto calendar user address for iMIP (usually with  a domain
>> set to the calendar server host and an "opaque" identifier  for thew
>> local part). In such a case there could be two email  addresses on a
>> property: one in the EMAIL paramater (the 3rd party  address that could
>> be matched to a contact record); and the other the  calendar user address
>> value in the property.
>>
> I think I meant only if the value is not a mailto:. I assume in the absence
> of any other indication (e.g. a valid email) this might be a fallback?

Of course you can send an iMIP message to any email address and hope it gets 
to the right place! I think the poiunt here is that it should never have to 
be used as a fallback. The ORGANIZER or ATTENDEE property values should be 
mailto's if the intent is to use iMIP. You pasted an example iCalendar 
message below which illustrates the point. The EMAIL parameter has a gmail 
domain, whilst the CUA value is me.com. Sending an iMIP to the EMAIL address 
would result in the scheduling message being intercepted and stored on the 
Google calendar, and not the iCloud calendar.

> One of those was generated by Apple. I created an event yesterday which in
> full is
>
> BEGIN:VCALENDAR
> PRODID:-//CALENDARSERVER.ORG//NONSGML Version 1//EN
> METHOD:REQUEST
> VERSION:2.0
> BEGIN:VEVENT
> DTEND;TZID=America/New_York:20210219T100000
> DTSTART;TZID=America/New_York:20210219T090000
> ORGANIZER;CN=Michael Douglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T
>   GNJSHAZTSMZVGI4DGOJTGW7UOVQIXU6S7IXFKVSLJVS4VP4YX5J2UCRWN6KC2YMIGY25PWAA
>   I@imip.me.com
> UID:E5C6F579-5003-4755-B29D-572E0FF147B1
> DTSTAMP:20210217T051817Z
> SEQUENCE:1
> SUMMARY:Testing email param
> LAST-MODIFIED:20210217T051817Z
> CREATED:20210217T051744Z
> ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com;RSVP=TRUE;PARTSTA
>   T=NEEDS-ACTION:mailto:mdouglass@bedework.com
> ATTENDEE;CN=Ken Murchison;CUTYPE=INDIVIDUAL;EMAIL=murch@fastmail.com;RSVP
>   =TRUE;PARTSTAT=NEEDS-ACTION:mailto:murch@fastmail.com
> ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA
>   IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
>   cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
> END:VEVENT

Well that may well be a bug!

> I believe a URI doesn't require a scheme - a simple path is sufficient

I think the syntax and associated text in 
https://www.rfc-editor.org/rfc/rfc3986#section-3 make it pretty clear a 
scheme is required.

-- 
Cyrus Daboo

v2.8.7 | Report a Bug | By Email