Subject: [Jcardcal] Finally a new jCal version!

From: Philipp Kewisch <[email-masked]>
Date: Mon, 09 Dec 2013 22:25:55 +0100

Hey Folks,

sorry for the long delay, I'll try to get this on the road asap now. 
I've just submitted a new draft for jCal, containing some editorial 
changes in alignment with the jCard drafts. There is one open issue I'd 
like to discuss:

There is a text about removing the base64 encoding when the value type 
is not BINARY. I don't think this is the right thing to do, why should 
we be changing the content here? This might be a risk for not preserving 
semantics correctly when round-tripping. Here is the text:

  iCalendar uses a base64 encoding for binary data.  However, it does
    not restrict the encoding from being applied to non-binary value
    types.  So the following rules MUST be applied when processing a
    property with the "ENCODING" property parameter set to "BASE64":

    o  If the property value type is "BINARY", the base64 encoding MUST
       be preserved.

    o  If the value type is not "BINARY", the "ENCODING" property
       parameter MUST be removed, and the value MUST be base64 decoded.

    When base64 encoding and decoding is used, it MUST conform to
    Section 4 of [RFC4648]  <http://tools.ietf.org/html/rfc4648#section-4>, which is the base64 method used in [RFC5545  <http://tools.ietf.org/html/rfc5545>].

Cyrus, Mike, I'd especially appreciate your input here as I believe this 
text is from before I took over the authoring.

As this is a very minor issue, I think we should go ahead with the last 
call and fix it at latest during the final reviews.

Thanks,
Philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Dec 2013 14:39:48 -0700

On 12/9/13 2:25 PM, Philipp Kewisch wrote:
> changes in alignment with the jCard drafts.

Thank you, Philipp! I will review the diff and compare it to the work
you did on jCard.

> call and fix it at latest during the final reviews.

Yes, it seems reasonable to handle this issue during WGLC, which I will
attempt to initiate as quickly as possible.

As chair,

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Dec 2013 15:13:43 -0700

> attempt to initiate as quickly as possible.

Sorry about the confusion, this I-D has already undergone WGLC... :-)

http://www.ietf.org/mail-archive/web/jcardcal/current/msg00241.html

These changes were done to align with the changes to jCard made as a
result of IETF Last Call and IESG review. The next step for jCal is IETF
Last Call, but I need to prepare the shepherd's writeup before that can
start. Expect IETF Last Call to be longer than the usual two weeks given
end-of-year holidays and such.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Philipp Kewisch <[email-masked]>
Date: Mon, 09 Dec 2013 23:15:35 +0100

> end-of-year holidays and such.
Ah perfect. I was wondering why the last version only had such minor 
changes. Thats fine with me.

Philipp