Implement RFC 6868 caret encoding for parameter values

[gaoflow]

A newline in a property parameter value makes Calendar.Load(Serialize(cal)) throw: the raw newline terminates the content line, so ical.net emits output its own parser rejects.

att.Parameters.Set("CN", "line1\nline2");
// Load(Serialize(cal)) -> SerializationException: missing colon

RFC 6868 is the standard remedy and was unimplemented. This adds the symmetric codec: encode ^->^^, DQUOTE->^', newline->^n on serialization (§3.1) and the exact inverse when parsing parameter values (§3.2), each a single left-to-right pass.

DQUOTE was previously stripped, under a comment that parameter values MUST NOT contain DQUOTE. RFC 6868 ^' keeps that guarantee (no literal DQUOTE reaches the wire) while round-tripping the character instead of dropping it, so I implemented that half too.

Tests cover decode(encode(v)) == v for ^, newline, DQUOTE, a literal ^n/^^ and mixed values, the Load(Serialize()) round-trip through the public API, and that plain values stay byte-identical. Full suite passes on net10.0; net8.0/net48 build (no net8 runtime on my machine to run them).

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[maknapp]

@gaoflow, you appear to be mass committing to a bunch of repos. Does this issue directly affect you in any way? Do you know which major calendar services implement this?

[gaoflow]

Hi @maknapp — fair question. Yes, I've been sending correctness fixes across a number of libraries; the account is AI-assisted (an agent finds and drafts the fix) but run under my direction, and I'm accountable for everything that goes in, so I'm glad to drop anything that isn't wanted.

I don't have a production dependency on Ical.Net here — I found this while auditing the serializer against RFC 6868/5545, where a parameter value containing a double-quote or newline currently can't round-trip. I don't have a survey of which calendar clients decode 6868, so if the real-world payoff feels too thin, I'm fine with you closing it — no argument.

[codecov]

Codecov Report

❌ Patch coverage is 92.85714% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
Ical.Net/Serialization/CaretEncoding.cs	92.3%	0 Missing and 2 partials ⚠️

@@           Coverage Diff           @@
##            main    #969     +/-   ##
=======================================
+ Coverage   72.0%   72.1%   +0.1%     
=======================================
  Files        118     119      +1     
  Lines       4672    4698     +26     
  Branches    1090    1098      +8     
=======================================
+ Hits        3362    3386     +24     
  Misses       956     956             
- Partials     354     356      +2     

Files with missing lines	Coverage Δ
Ical.Net/Serialization/ParameterSerializer.cs	61.5% <100.0%> (ø)
Ical.Net/Serialization/SimpleDeserializer.cs	93.2% <100.0%> (ø)
Ical.Net/Serialization/CaretEncoding.cs	92.3% <92.3%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[maknapp]

While this looks to be backwards compatible, it might not be a good idea to support this if no major calendar providers support this. I tried to add an ATTENDEE to a Google Calendar event as shown in the RFC example, but Google just silently ignored the ATTENDEE. I did not test any other calendars. Throwing an exception in ical.net would at least notify the user, although the exception could be better than "missing colon."

Could also have serializing options to enable support if it is not too complicated.

@axunonb Any opinions on this?