Parameter Value Encoding in iCalendar and vCard
draft-daboo-ical-vcard-parameter-encoding-04

[Ballot comment]

Hilarie Orman's secdir review is good but requires no action.
She said: "The document defines a character escape mechanism.
This is not a literary device, but a way of encoding the
double-quote and linefeed characters in vcard entries."

[Ballot discuss]
Some of the normative requirements listed in Section 3 seem wrong:

  When generating iCalendar or vCard parameter values, the characters
  in the second column above MUST be escaped using the sequence from
  the first column.

That one is fine.

  When parsing iCalendar or vCard parameter values,
  the two character sequence from the first column MUST be replaced by
  the single character from the second column.

The above is nonsense. If in my internal implementation, I wish to replace "^n" with U+2028 (and also generate an "^n" when my internal representation has a U+2028), that's perfectly reasonable and this document has no business telling me I MUST do otherwise. In fact, you say as much below. (Personally, I see no reason not to specify U+2028 as the line separator and not use LF for that purpose to avoid the need to escape LF, but that's not a DISCUSSion issue.)

  If a ^ (U+005E)
  character is followed by any other character than the ones above,
  parsers SHOULD leave the ^ character in place.

Again, I don't think you ought to be telling *parsers* what they SHOULD (or MUST) do.

  In addition to the escaping procedure outlined above, text parameter
  values MUST also have line break character sequences canonicalized
  into a single line feed (U+000A) character when the parameter value
  is generated.

Don't you instead mean that "text parameter values MUST also have line break character sequences canonicalized into the sequence '^n' when the parameter value is generated?

  Specifically, any single carriage return character
  (U+000D) or the two character combination of carriage return followed
  by line feed (U+000D, U+000A) MUST be mapped to ^n in the generated
  parameter value.

That's OK. Do you want to mention U+2028 also?

  When parsing a parameter value with ^n, clients can
  replace that with the appropriate line break character sequence for
  the system they are running on.

Right.

IANA has reviewed draft-daboo-ical-vcard-parameter-encoding-02, which
is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Parameter Value Encoding in iCalendar and vCard) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Parameter Value Encoding in iCalendar and vCard'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-12-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification updates the iCalendar and vCard data formats to
  allow parameter values to include certain characters forbidden by the
  existing specifications.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-daboo-ical-vcard-parameter-encoding/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-daboo-ical-vcard-parameter-encoding/ballot/


No IPR declarations have been submitted directly on this I-D.

Document shepherd writeup:

1. Summary

The document shepherd is Mike Douglass. The responsible Area Director
is Barry Leiba.

This specification updates the data formats for iCalendar (RFC 5545)
and vCard (RFC 6350) to allow parameter values to include certain
characters forbidden by the existing specifications.

2. Review and Consensus

The extension is straightforward, and there was little discussion before
coming to consensus. What discussion there was took place on the
Calsify  and vCardDAV  mailing lists.

The choice of escape character and sequences allows the new functionality
without compromising existing software and justification for the final form of
escaping appears as an appendix to the current draft. There are a small
number of implementations already and more are planned.

3. Intellectual Property

The author has confirmed conformance with BCP 78/79. There are no IPR
disclosures on the document.

4. Other Points

The document updates RFCs 5545 and 6350, and the reasons for the updates
are clearly explained in the introduction.  The abstract mentions the updates
by name, and the RFC numbers will be added in an RFC Editor note.