Re: [calsify] [Technical Errata Reported] RFC5545 (7691)

[Eliot Lear <[e-mail]>]

Hi Syd,

Thanks for the report.  Because altrepparam in this case contains a “uri" and the URI text is specified in RFC 3896, and this is not TEXT, I agree with your assessment, and that this erratum should be verified.  Do others disagree?

Eliot

> On Oct 30, 2023, at 08:20, RFC Errata System <[e-mail]> wrote:
> 
> The following errata report has been submitted for RFC5545,
> "Internet Calendaring and Scheduling Core Object Specification (iCalendar)".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7691
> 
> --------------------------------------
> Type: Technical
> Reported by: Tom Sydney Kerckhove <[e-mail]>
> 
> Section: 3.8.4.2
> 
> Original Text
> -------------
> The following is an example of this property with an alternate
> representation of an LDAP URI to a directory entry containing the
> contact information:
> 
> CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\,
> c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\,
> [phone]
> 
> Corrected Text
> --------------
> The following is an example of this property with an alternate
> representation of an LDAP URI to a directory entry containing the
> contact information:
> 
> CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries,
> c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\,
> [phone]
> 
> Notes
> -----
> Note that the original text has an escaped comma in the ALTREP parameter value at the end of the unfolded line.
> 
> The characters '\' and ',' are allowed in quoted parameter values.
> This means that the URL must be parsed as
> "ldap://example.com:6666/o=ABC%20Industries\,c=US???(cn=Jim%20Dolittle)"
> but this is not a valid URI because of the extra backslash.
> 
> Because commas do not need to be escaped in quoted parameter values, I assume that this is an error and the comma should not have been quoted.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC5545 (draft-ietf-calsify-rfc2445bis-10)
> --------------------------------------
> Title               : Internet Calendaring and Scheduling Core Object Specification (iCalendar)
> Publication Date    : September 2009
> Author(s)           : B. Desruisseaux, Ed.
> Category            : PROPOSED STANDARD
> Source              : Calendaring and Scheduling Standards Simplification
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG