Re: [calsify] [Technical Errata Reported] RFC9073 (7381)

[Francesca Palombini <[e-mail]>]

Ok, from this discussion I have a question. Is this something that was intended to be the way it’s written (in which case I will mark Hold for doc update) or it is something that was omitted and if it was caught at the time of writing it would have been fixed (in which case I will mark verified)?

On another note, is there not a “/” missing after “name” (or after “url” if the errata is verified)?

Francesca


From: Ken Murchison <[e-mail]>
Date: Thursday, 9 November 2023 at 11:19
To: RFC Errata System <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Francesca Palombini <[e-mail]>, [e-mail] <[e-mail]>, Daniel Migault <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [calsify] [Technical Errata Reported] RFC9073 (7381)
As Mike stated in a reply to just the calsify list, the URL property is
covered by iana-prop in the ABNF for locprop, so I don't know if this
should be marked as verified or hold for doc update.  I'll leave that
decision to Francesca.


On 11/7/23 11:26 AM, Ken Murchison wrote:
> This also looks like it should be verified, as RFC 9074 definitely
> wants support for an uncertainly value along with the location and the
> RFC 5545 GEO property doesn't give us that.
>
>
> On 3/9/23 4:51 AM, RFC Errata System wrote:
>> The following errata report has been submitted for RFC9073,
>> "Event Publishing Extensions to iCalendar".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid7381
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Olaf Bartelt <[e-mail]>
>>
>> Section: 7.2
>>
>> Original Text
>> -------------
>>     Format Definition:  This component is defined by the following
>>        notation:
>>
>>        locationc    = "BEGIN" ":" "VLOCATION" CRLF
>>                       locprop
>>                       "END" ":" "VLOCATION" CRLF
>>
>>        locprop      = *(
>>                       ;
>>                       ; The following are REQUIRED
>>                       ; but MUST NOT occur more than once.
>>                       ;
>>                       uid /
>>                       ;
>>                       ; The following are OPTIONAL
>>                       ; but MUST NOT occur more than once.
>>                       ;
>>                       description / geo / loctype / name
>>                       ;
>>                       ; The following are OPTIONAL
>>                       ; and MAY occur more than once.
>>                       ;
>>                       sdataprop / iana-prop
>>                    )
>>
>> Corrected Text
>> --------------
>>     Format Definition:  This component is defined by the following
>>        notation:
>>
>>        locationc    = "BEGIN" ":" "VLOCATION" CRLF
>>                       locprop
>>                       "END" ":" "VLOCATION" CRLF
>>
>>        locprop      = *(
>>                       ;
>>                       ; The following are REQUIRED
>>                       ; but MUST NOT occur more than once.
>>                       ;
>>                       uid /
>>                       ;
>>                       ; The following are OPTIONAL
>>                       ; but MUST NOT occur more than once.
>>                       ;
>>                       description / geo / loctype / name / url
>>                       ;
>>                       ; The following are OPTIONAL
>>                       ; and MAY occur more than once.
>>                       ;
>>                       sdataprop / iana-prop
>>                    )
>>
>> Notes
>> -----
>> The url property is missing or the specification clahes with RFC
>> 9074, where in section 8.2 in the example it reads:
>>
>>     BEGIN:VLOCATION
>>     UID:123456-abcdef-98765432
>>     NAME:Office
>>     URL:geo:40.443,-79.945;u=10
>>     END:VLOCATION
>>
>> Either "geo" was intended as a geo uri as defined in RFC 5870
>> (instead of the geographic position from RFC 2445/5545) or "url"
>> should be added as a valid property (or RFC 9074 is wrong).
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC9073 (draft-ietf-calext-eventpub-extensions-19)
>> --------------------------------------
>> Title               : Event Publishing Extensions to iCalendar
>> Publication Date    : August 2021
>> Author(s)           : M. Douglass
>> Category            : PROPOSED STANDARD
>> Source              : Calendaring Extensions
>> Area                : Applications and Real-Time
>> Stream              : IETF
>> Verifying Party     : IESG
>>
--
Kenneth Murchison
Senior Software Developer
Fastmail US LLC