Subject: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-valarm-extensions-05: (with DISCUSS)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 23 Feb 2021 19:49:56 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-calext-valarm-extensions-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-calext-valarm-extensions/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Please update to reflect the changes made in draft-ietf-calext-eventpub-extensions-17
(e.g., there is no longer STRUCTURED-LOCATION and VLOCATION plays a similar
role).

---

From: Barry Leiba <[email-masked]>
Date: Tue, 23 Feb 2021 23:16:38 -0500

Indeed: this change came up in the IESG Evaluation of
eventpub-extensions, and was made shortly before valarm-extensions-04
was posted.  And I missed catching that issue when I moved
valarm-extensions into IESG Evaluation.

This should not be a big thing to fix in valarm-extensions, as the
real meat of VLOCATION is in eventpub-extensions.

Barry

---

From: Ken Murchison <[email-masked]>
Date: Wed, 24 Feb 2021 08:00:29 -0500

Hi Benjamin,

Thanks for catching this.  I will address this as soon as the blackout 
on submitting drafts has been lifted.

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: Ken Murchison <[email-masked]>
Date: Wed, 24 Feb 2021 12:38:09 -0500

All,

So, Mike Douglass and I were just discussing this and we came to the 
conclusion that the best place to put the geographic coordinates is 
going to be in a URL property rather than a GEO property, because the 
latter only encodes latitude and longitude. So, the proximity alarm 
would look something like this:

BEGIN:VALARM
UID:77D80D14-906B-4257-963F-85B1E734DBB6
TRIGGER;VALUE=DATE-TIME:19760401T005545Z
ACTION:DISPLAY
DESCRIPTION:Remember to buy milk
TRIGGER;VALUE=DATE-TIME:19760401T005545Z
PROXIMITY:DEPART
BEGIN:VLOCATION
UID:123456-abcdef-98765432
NAME:Office
URL:geo:40.443,-79.945;u=10
END:VLOCATION
END:VALARM

Does anyone have any objections, or other suggestions?

On 2/24/21 8:00 AM, Ken Murchison wrote:
>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Daniel Migault <[email-masked]>
Date: Wed, 24 Feb 2021 20:47:00 +0000

Seems fine to me.
Yours,
Daniel

From: calsify <[email-masked]> On Behalf Of Ken Murchison
Sent: Wednesday, February 24, 2021 12:38 PM
To: Calsify <[email-masked]>
Cc: [email-masked]
Subject: Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-valarm-extensions-05: (with DISCUSS)

All,

So, Mike Douglass and I were just discussing this and we came to the conclusion that the best place to put the geographic coordinates is going to be in a URL property rather than a GEO property, because the latter only encodes latitude and longitude.  So, the proximity alarm would look something like this:

BEGIN:VALARM

ACTION:DISPLAY

PROXIMITY:DEPART

BEGIN:VLOCATION

NAME:Office

END:VLOCATION

END:VALARM

Thanks for catching this.  I will address this as soon as the blackout on submitting drafts has been lifted.

--

Kenneth Murchison

Fastmail US LLC