From cyrus@daboo.name Mon May 23 16:20:07 2011 Return-Path: X-Original-To: icalendar@ietfa.amsl.com Delivered-To: icalendar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B55E07DB for ; Mon, 23 May 2011 16:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7denP37AWXHv for ; Mon, 23 May 2011 16:20:06 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by ietfa.amsl.com (Postfix) with ESMTP id ED0DAE07DD for ; Mon, 23 May 2011 16:20:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 760589C0940; Mon, 23 May 2011 19:20:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHXK5CIkrAaM; Mon, 23 May 2011 19:20:05 -0400 (EDT) Received: from [17.151.72.140] (unknown [17.151.72.140]) by daboo.name (Postfix) with ESMTPSA id 52A049C092F; Mon, 23 May 2011 19:20:04 -0400 (EDT) Date: Mon, 23 May 2011 16:20:32 -0700 From: Cyrus Daboo To: icalendar@ietf.org, iana@iana.org Message-ID: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=466 Cc: Peter Saint-Andre Subject: [icalendar] Registration of new iCalendar property X-BeenThere: icalendar@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: iCalendar List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 23:20:07 -0000 Hi, As per the requirements of the iCalendar IANA registration procedures I am requesting approval of a new iCalendar property registration. This property is being registered by draft-daboo-et-al-icalendar-in-xml-09. In particular, Section 7.3 lists the new items and the section where its template is defined. Note: I am one of the designated expert reviewers for this registry but will recuse myself since I am a co-author of this document. -- Cyrus Daboo From bernard.desruisseaux@oracle.com Thu May 26 17:50:43 2011 Return-Path: X-Original-To: icalendar@ietfa.amsl.com Delivered-To: icalendar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EF6E068C for ; Thu, 26 May 2011 17:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.598 X-Spam-Level: X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J98DV40hsFlf for ; Thu, 26 May 2011 17:50:42 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 368EBE0680 for ; Thu, 26 May 2011 17:50:42 -0700 (PDT) Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p4R0lgE9009472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 May 2011 00:47:44 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p4R0lc4Y018035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 May 2011 00:47:40 GMT Received: from hqdfmt01.oracle.com (hqdfmt01.oracle.com [148.87.24.194]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p4R0lWB7007221; Thu, 26 May 2011 19:47:32 -0500 Received: from [10.159.54.55] (/10.159.54.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 May 2011 17:47:31 -0700 USER-AGENT: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 X-ORACLE-DEBUG=STACK X-ORACLE-LIMIT=2500 OracleBeehiveExtension/1.1.0.0pre29-Alpha Thunderbird/3.1.10 MIME-Version: 1.0 Message-ID: <4DDEF49C.8080108@oracle.com> Date: Thu, 26 May 2011 17:47:24 -0700 (PDT) From: Bernard Desruisseaux To: iana-prot-param-comment@iana.org, icalendar@ietf.org, iana@iana.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080900000602030107080400" Content-Transfer-Encoding: 7bit X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090202.4DDEF4B2.0090,ss=1,fgs=0 Cc: draft-daboo-et-al-icalendar-in-xml@tools.ietf.org, Peter Saint-Andre Subject: Re: [icalendar] [IANA #453987] Registration of new iCalendar property X-BeenThere: icalendar@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: iCalendar List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 00:50:43 -0000 --------------080900000602030107080400 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Here's my review of section 4.2 of draft-daboo-et-al-icalendar-in-xml-10: 1- Change: Purpose: To embed XML-encoded calendar data in the iCalendar format to: Purpose: To embed extended XML-encoded iCalendar data in the iCalendar format 2- Change: Conformance: The property can appear on any iCalendar component. to: Conformance: This property can be specified multiple times in any calendar component. 3- Text should make it clear whether the value can include an XML declaration or not (i.e., ). 4- May want to remove or relax the restriction on "X-" iCalendar extension property in the following paragraph, since one never can tell whether there is such an extension being used out there. The "XML" property MUST NOT be used to contain properties that are already defined in iCalendar, or properties that use the "X-" iCalendar extension property syntax. 5- Change: Note that the source XML may contain characters not allowed in iCalendar such as control characters. to: Note that the source XML may contain characters not allowed in "TEXT" property values. It might also be a good idea to talk about the special characters that can simply be escaped with a BACKSLASH.. 6- Change: There can be more than one "XML" property present for a given iCalendar object. The ordering of "XML" properties is not preserved in the conversion between xCal and iCalendar. to: The ordering of "XML" properties is not preserved in the conversion between xCal and iCalendar. 7- The example is not a valid iCalendar object. DTSTART is missing the VALUE parameter (i.e., DTSTART;*VALUE=DATE*:20081006). There is actually no need to specify a complete iCalendar object as an example. Please consider providing a complete XML example instead (i.e., without "..."). Cheers, Bernard On 5/25/2011 1:53 PM, Amanda Baber via RT wrote: > Hi Bernard, > > As one of the designated experts for iCalendar, can you review this > proposed registration for us? > > thanks, > > Amanda Baber > IANA > > === > > Hi, > As per the requirements of the iCalendar IANA registration procedures I > am requesting approval of a new iCalendar property registration. This > property is being registered by draft-daboo-et-al-icalendar-in-xml-09. > In particular, Section 7.3 lists the new items and the section where its > template is defined. > > Note: I am one of the designated expert reviewers for this registry but > will recuse myself since I am a co-author of this document. > --------------080900000602030107080400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Here's my review of section 4.2 of draft-daboo-et-al-icalendar-in-xml-10:

1- Change:
   Purpose: To embed XML-encoded calendar data in the iCalendar format
to:
   Purpose: To embed extended XML-encoded iCalendar data in the iCalendar format
2- Change:
   Conformance: The property can appear on any iCalendar component.
to:
   Conformance: This property can be specified multiple times in any
      calendar component.

3- Text should make it clear whether the value can include an XML declaration or not (i.e., <?xml version="1.0" ... ?>).


4- May want to remove or relax the restriction on "X-" iCalendar extension property in the following paragraph, since one never can tell whether there is such an extension being used out there.
   The "XML"
   property MUST NOT be used to contain properties that are already
   defined in iCalendar, or properties that use the "X-" iCalendar
   extension property syntax.

5- Change:
   Note that the source XML may contain characters not allowed in
   iCalendar such as control characters.
to:
   Note that the source XML may contain characters not allowed in
   "TEXT" property values.
It might also be a good idea to talk about the special characters that can simply be escaped with a BACKSLASH..


6- Change:
   There can be more than one "XML" property present for a given
   iCalendar object.  The ordering of "XML" properties is not preserved
   in the conversion between xCal and iCalendar.
to:
   The ordering of "XML" properties is not preserved in the conversion
   between xCal and iCalendar.

7- The example is not a valid iCalendar object.  DTSTART is missing the VALUE parameter (i.e., DTSTART;VALUE=DATE:20081006).  There is actually no need to specify a complete iCalendar object as an example.  Please consider providing a complete XML example instead (i.e., without "...").

Cheers,
Bernard

On 5/25/2011 1:53 PM, Amanda Baber via RT wrote: 
Hi Bernard,

As one of the designated experts for iCalendar, can you review this
proposed registration for us?

thanks,

Amanda Baber
IANA

===

Hi,
As per the requirements of the iCalendar IANA registration procedures I
am requesting approval of a new iCalendar property registration. This
property is being registered by draft-daboo-et-al-icalendar-in-xml-09.
In particular, Section 7.3 lists the new items and the section where its
template is defined.

Note: I am one of the designated expert reviewers for this registry but
will recuse myself since I am a co-author of this document.

--------------080900000602030107080400-- From phillip@shingl.com Thu May 26 18:29:46 2011 Return-Path: X-Original-To: icalendar@ietfa.amsl.com Delivered-To: icalendar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E224CE0745 for ; Thu, 26 May 2011 18:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpz8kPvN4w1M for ; Thu, 26 May 2011 18:29:45 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with SMTP id 1CE5FE0697 for ; Thu, 26 May 2011 18:29:45 -0700 (PDT) Received: from mail-qw0-f45.google.com ([209.85.216.45]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTd7+iDWfBEKgPK+vdXmbveOsovP4fmNH@postini.com; Thu, 26 May 2011 18:29:45 PDT Received: by qwj8 with SMTP id 8so1041154qwj.18 for ; Thu, 26 May 2011 18:29:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.101.36 with SMTP id a36mr1208690qco.74.1306459783643; Thu, 26 May 2011 18:29:43 -0700 (PDT) Received: by 10.229.188.146 with HTTP; Thu, 26 May 2011 18:29:43 -0700 (PDT) In-Reply-To: <4DDEF49C.8080108@oracle.com> References: <4DDEF49C.8080108@oracle.com> Date: Thu, 26 May 2011 18:29:43 -0700 Message-ID: From: Phillip Mienk To: Bernard Desruisseaux Content-Type: multipart/alternative; boundary=0016364ee01e51441b04a437df5a Cc: draft-daboo-et-al-icalendar-in-xml@tools.ietf.org, icalendar@ietf.org, Peter Saint-Andre , iana-prot-param-comment@iana.org, iana@iana.org Subject: Re: [icalendar] [IANA #453987] Registration of new iCalendar property X-BeenThere: icalendar@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: iCalendar List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 01:29:47 -0000 --0016364ee01e51441b04a437df5a Content-Type: text/plain; charset=ISO-8859-1 I'm new to this list and in looking over the draft, I have a question about the fundamental intent of iana-tokens. In my reading of rfc5545 I was under the impression that properties (and by extension iana-tokens) were meant to encode semantic information. Is this inference in error? It appears to me that the concept of xml-encoding is akin to the difference between a date and date-time. In the same way that the start and end of an appointment are encoded by DTSTART and DTEND as opposed to some 'DATETIME' or 'DATE' property. I would think that the semantic title of the content of the xml-encoded information would be the intended token/property name and the encoding be communicated via parameter. Please let me know where I have strayed in my understanding. -- Phillip Mienk On Thu, May 26, 2011 at 5:47 PM, Bernard Desruisseaux < bernard.desruisseaux@oracle.com> wrote: > Here's my review of section 4.2 of draft-daboo-et-al-icalendar-in-xml-10: > > 1- Change: > > Purpose: To embed XML-encoded calendar data in the iCalendar format > > to: > > Purpose: To embed extended XML-encoded iCalendar data in the iCalendar format > > > 2- Change: > > Conformance: The property can appear on any iCalendar component. > > to: > > Conformance: This property can be specified multiple times in any > calendar component. > > > 3- Text should make it clear whether the value can include an XML > declaration or not (i.e., ). > > > 4- May want to remove or relax the restriction on "X-" iCalendar extension > property in the following paragraph, since one never can tell whether there > is such an extension being used out there. > > The "XML" > property MUST NOT be used to contain properties that are already > defined in iCalendar, or properties that use the "X-" iCalendar > extension property syntax. > > > 5- Change: > > Note that the source XML may contain characters not allowed in > iCalendar such as control characters. > > to: > > Note that the source XML may contain characters not allowed in > "TEXT" property values. > > It might also be a good idea to talk about the special characters that can > simply be escaped with a BACKSLASH.. > > > 6- Change: > > There can be more than one "XML" property present for a given > iCalendar object. The ordering of "XML" properties is not preserved > in the conversion between xCal and iCalendar. > > to: > > The ordering of "XML" properties is not preserved in the conversion > between xCal and iCalendar. > > > 7- The example is not a valid iCalendar object. DTSTART is missing the > VALUE parameter (i.e., DTSTART;*VALUE=DATE*:20081006). There is actually > no need to specify a complete iCalendar object as an example. Please > consider providing a complete XML example instead (i.e., without "..."). > > Cheers, > Bernard > > On 5/25/2011 1:53 PM, Amanda Baber via RT wrote: > > Hi Bernard, > > As one of the designated experts for iCalendar, can you review this > proposed registration for us? > > thanks, > > Amanda Baber > IANA > > === > > Hi, > As per the requirements of the iCalendar IANA registration procedures I > am requesting approval of a new iCalendar property registration. This > property is being registered by draft-daboo-et-al-icalendar-in-xml-09. > In particular, Section 7.3 lists the new items and the section where its > template is defined. > > Note: I am one of the designated expert reviewers for this registry but > will recuse myself since I am a co-author of this document. > > > > > _______________________________________________ > icalendar mailing list > icalendar@ietf.org > https://www.ietf.org/mailman/listinfo/icalendar > > --0016364ee01e51441b04a437df5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm new to this list and in looking over the draft, I have a question a= bout the fundamental intent of iana-tokens.=A0 In my reading of rfc5545 I w= as under the impression that properties (and by extension iana-tokens) were= meant to encode semantic information.=A0 Is this inference in error?

It appears to me that the concept of xml-encoding is akin to the differ= ence between a date and date-time.=A0 In the same way that the start and en= d of an appointment are encoded by DTSTART and DTEND as opposed to some = 9;DATETIME' or 'DATE' property.=A0 I would think that the seman= tic title of the content of the xml-encoded information would be the intend= ed token/property name and the encoding be communicated via parameter.

Please let me know where I have strayed in my understanding.

-- = Phillip Mienk

On Thu, May 26, 2011 at 5:4= 7 PM, Bernard Desruisseaux <bernard.desruisseaux@oracle.com> wro= te:
=20 =20 =20 =20
Here's my review of section 4.2 of draft-daboo-et-al-icalendar-in-xml-10:

1- Change:
   Purpose: To embed XML-encoded calendar data in the iCalendar fo=
rmat
to:
   Purpose: To embed extended XML-encoded iCalendar data in the iC=
alendar format
2- Change:
=A0=A0 Conformance: The property can appear on any iCalendar compo=
nent.
to:
=A0=A0 Conformance: This property can be specified multiple times =
in any
      calendar component.

3- Text should make it clear whether the value can include an XML declaration or not (i.e., <?xml version=3D"= ;1.0" ... ?>).


4- May want to remove or relax the restriction on "X-" iCalen= dar extension property in the following paragraph, since one never can tell whether there is such an extension being used out there.
   The "XML"
   property MUST NOT be used to contain properties that are already
   defined in iCalendar, or properties that use the "X-" iCalenda=
r
   extension property syntax.

5- Change:
   Note that the source XML may contain characters not allowed in
   iCalendar such as control characters.
to:
   Note that the source XML may contain characters not allowed in
   "TEXT" property values.
It might also be a good idea to talk about the special characters that can simply be escaped with a BACKSLASH..


6- Change:
   There can be more than one "XML" property present for=
 a given
   iCalendar object.  The ordering of "XML" properties is not pre=
served
   in the conversion between xCal and iCalendar.
to:
   The ordering of "XML" properties is not preserved in =
the conversion
   between xCal and iCalendar.

7- The example is not a valid iCalendar object.=A0 DTSTART is missing the VALUE parameter (i.e., DTSTART;VALUE=3DDATE:20081006).=A0 There is actually no need to specify a complete iCalendar object as an example.=A0 Please consider providing a complete XML example instead (i.e., without "...").

Cheers,
Bernard

On 5/25/2011 1:53 PM, Amanda Baber via RT wrote: 
Hi Bernard,

As one of the designated experts for iCalendar, can you review this
proposed registration for us?

thanks,

Amanda Baber
IANA

=3D=3D=3D

Hi,
As per the requirements of the iCalendar IANA registration procedures I
am requesting approval of a new iCalendar property registration. This
property is being registered by draft-daboo-et-al-icalendar-in-xml-09.
In particular, Section 7.3 lists the new items and the section where its
template is defined.

Note: I am one of the designated expert reviewers for this registry but
will recuse myself since I am a co-author of this document.


_______________________________________________
icalendar mailing list
icalendar@ietf.org
https://www.ietf.org/mailman/listinfo/icalendar


--0016364ee01e51441b04a437df5a-- From cyrus@daboo.name Fri May 27 07:09:48 2011 Return-Path: X-Original-To: icalendar@ietfa.amsl.com Delivered-To: icalendar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E42CE06DD for ; Fri, 27 May 2011 07:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.602 X-Spam-Level: X-Spam-Status: No, score=-100.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfBdInQSqPgA for ; Fri, 27 May 2011 07:09:46 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by ietfa.amsl.com (Postfix) with ESMTP id 63DB6E06DA for ; Fri, 27 May 2011 07:09:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 0C886A79F5A; Fri, 27 May 2011 10:09:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yxOtcSh+qFF; Fri, 27 May 2011 10:09:36 -0400 (EDT) Received: from [17.151.71.145] (unknown [208.51.138.98]) by daboo.name (Postfix) with ESMTPSA id C262DA79F45; Fri, 27 May 2011 10:09:33 -0400 (EDT) Date: Fri, 27 May 2011 07:09:33 -0700 From: Cyrus Daboo To: Bernard Desruisseaux , iana-prot-param-comment@iana.org, icalendar@ietf.org, iana@iana.org Message-ID: <715DF9985D2BFC1C75434F9B@wdyn-50-139.arc.nasa.gov> In-Reply-To: <4DDEF49C.8080108@oracle.com> References: <4DDEF49C.8080108@oracle.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========C32029A1482AA24E6B9A==========" Cc: draft-daboo-et-al-icalendar-in-xml@tools.ietf.org, Peter Saint-Andre Subject: Re: [icalendar] [IANA #453987] Registration of new iCalendar property X-BeenThere: icalendar@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: iCalendar List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 14:09:48 -0000 --==========C32029A1482AA24E6B9A========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=2577 Hi Bernard, --On May 26, 2011 5:47:24 PM -0700 Bernard Desruisseaux=20 wrote: > Here's my review of section 4.2 of draft-daboo-et-al-icalendar-in-xml-10: > > 1- Change: > > Purpose: To embed XML-encoded calendar data in the iCalendar format > to: > > Purpose: To embed extended XML-encoded iCalendar data in the iCalendar > format Fixed. > 2- Change: > > =C2=A0=C2=A0 Conformance: The property can appear on any iCalendar = component. > to: > > =C2=A0=C2=A0 Conformance: This property can be specified multiple times = in any > calendar component. Fixed. > 3- Text should make it clear whether the value can include an XML > declaration or not (i.e., ). I have taken text from the vcardxml spec that states clearly that the=20 embedded XML must be version 1.0. Hence there is no need for the = declaration. > 4- May want to remove or relax the restriction on "X-" iCalendar > extension property in the following paragraph, since one never can tell > whether there is such an extension being used out there. > > The "XML" > property MUST NOT be used to contain properties that are already > defined in iCalendar, or properties that use the "X-" iCalendar > extension property syntax. Fixed by removing. > > 5- Change: > > Note that the source XML may contain characters not allowed in > iCalendar such as control characters. > to: > > Note that the source XML may contain characters not allowed in > "TEXT" property values. > It might also be a good idea to talk about the special characters that > can simply be escaped with a BACKSLASH.. Fixed. > 6- Change: > > There can be more than one "XML" property present for a given > iCalendar object. The ordering of "XML" properties is not preserved > in the conversion between xCal and iCalendar. > > to: > > The ordering of "XML" properties is not preserved in the conversion > between xCal and iCalendar. Fixed. > 7- The example is not a valid iCalendar object.=C2=A0 DTSTART is missing = the > VALUE parameter (i.e., DTSTART;VALUE=3DDATE:20081006).=C2=A0 There is = actually > no need to specify a complete iCalendar object as an example.=C2=A0 = Please > consider providing a complete XML example instead (i.e., without "..."). Fixed. I have included an example for the property only, but have added a=20 more complete sample of xml, including some backslash escaping. Please find attached an HTML diff with the proposed changes. Let me know if = this addresses all your comments and I will submit the new draft. --=20 Cyrus Daboo --==========C32029A1482AA24E6B9A========== Content-Type: text/html; charset=utf-8; name="rfcdiff.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="rfcdiff.html"; size=59275 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Diff: draft-daboo-et-al-icalendar-in-xml-10.txt - = draft-daboo-et-al-icalendar-in-xml-11.txt=20 =20 =20 =20 =20 =20 <= td class=3D"lineno" valign=3D"top">
< draft-daboo-et-al-icalendar-in-xml-10.txt   draft-daboo-et-al-icalendar-in-xml-11.txt >
Network Working Group = C. Daboo Network Working Group = C. Daboo
Internet-Draft = Apple, Inc. Internet-Draft = Apple, Inc.
Intended status: Standards Track = M. Douglass Intended status: Standards = Track M. Douglass
Expires: November 27, 2011 = RPI Expires: November 28, 2011 = RPI
= S. Lees = = S. Lees
= Microsoft = = Microsoft
= May 26, 2011 = May 27, 2011
= xCal: The XML format for iCalendar xCal: The XML format for = iCalendar
= draft-daboo-et-al-icalendar-in-xml-10 = draft-daboo-et-al-icalendar-in-xml-11
Abstract Abstract
= This specification defines "xCal", an XML format for iCalendar = data. This specification defines = "xCal", an XML format for iCalendar data.
Status of This Memo Status = of This Memo
= This Internet-Draft is submitted in full conformance with the = This Internet-Draft is submitted in full = conformance with the
= provisions of BCP 78 and BCP 79. = provisions of BCP 78 and BCP 79.
= Internet-Drafts are working documents of the Internet Engineering = Internet-Drafts are working documents of the = Internet Engineering
= Task Force (IETF). Note that other groups may also distribute = Task Force (IETF). Note that other groups may = also distribute
= working documents as Internet-Drafts. The list of current = Internet- working documents as = Internet-Drafts. The list of current Internet-
= Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at = http://datatracker.ietf.org/drafts/current/.
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
= and may be updated, replaced, or obsoleted by other documents at = any and may be updated, replaced, or = obsoleted by other documents at any
= time. It is inappropriate to use Internet-Drafts as reference = time. It is inappropriate to use = Internet-Drafts as reference
= material or to cite them other than as "work in progress." = material or to cite them other than as "work in = progress."
= This Internet-Draft will expire on November 27, 2011. This = Internet-Draft will expire on November 28, = 2011.
Copyright Notice Copyright = Notice
= Copyright (c) 2011 IETF Trust and the persons identified as the = Copyright (c) 2011 IETF Trust and the persons = identified as the
= document authors. All rights reserved. = document authors. All rights reserved.
= This document is subject to BCP 78 and the IETF Trust's Legal = This document is subject to BCP 78 and the IETF = Trust's Legal
= Provisions Relating to IETF Documents = Provisions Relating to IETF Documents
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://trustee.ietf.org/license-info) in = effect on the date of
= publication of this document. Please review these documents = publication of this document. Please review = these documents
skipping to change at page 2, line 40 = skipping to change at = page 2, line 40
= 3.6.10. Recurrence Rule (RFC5545 section 3.3.10) . . . . . . . 15 = 3.6.10. Recurrence Rule (RFC5545 section = 3.3.10) . . . . . . . 15
= 3.6.11. Text (RFC5545 section 3.3.11) . . . . . . . . . . . . 16 = 3.6.11. Text (RFC5545 section 3.3.11) . . = . . . . . . . . . . 16
= 3.6.12. Time (RFC5545 section 3.3.12) . . . . . . . . . . . . 16 = 3.6.12. Time (RFC5545 section 3.3.12) . . = . . . . . . . . . . 16
= 3.6.13. URI (RFC5545 section 3.3.13) . . . . . . . . . . . . . 16 = 3.6.13. URI (RFC5545 section 3.3.13) . . . = . . . . . . . . . . 16
= 3.6.14. UTC Offset (RFC5545 section 3.3.14) . . . . . . . . . 16 = 3.6.14. UTC Offset (RFC5545 section 3.3.14) = . . . . . . . . . 16
= 3.7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . = 17 3.7. Extensions . . . . . . . . = . . . . . . . . . . . . . . . . 17
4. = Converting from xCal into iCalendar . . . . . . . . . . . . . 17 = 4. Converting from xCal into iCalendar . . . = . . . . . . . . . . 17
= 4.1. Converting XML Extensions into iCalendar . . . . . . . . . = 17 4.1. Converting XML Extensions = into iCalendar . . . . . . . . . 17
= 4.2. The XML property for iCalendar . . . . . . . . . . . . . . = 18 4.2. The XML property for = iCalendar . . . . . . . . . . . . . . 18
5. = Handling Unrecognized Properties or Parameters . . . . . . . . 19 = 5. Handling Unrecognized Properties or = Parameters . . . . . . . . 19
= 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. = Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 = 7. IANA Considerations . . . . . . . . . . . = . . . . . . . . . . 21
= 7.1. Namespace Registration . . . . . . . . . . . . . . . . . . = 21 7.1. Namespace Registration . . = . . . . . . . . . . . . . . . . 21
= 7.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . . = 21 7.2. Media Type . . . . . . . . = . . . . . . . . . . . . . . . . 21
= 7.3. iCalendar Property Registrations . . . . . . . . . . . . . = 22 7.3. iCalendar Property = Registrations . . . . . . . . . . . . . 22
= 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 8. = Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. = References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 = 9. References . . . . . . . . . . . . . . . . = . . . . . . . . . . 23
= 9.1. Normative References . . . . . . . . . . . . . . . . . . . = 23 9.1. Normative References . . . = . . . . . . . . . . . . . . . . 23
= 9.2. Informative References . . . . . . . . . . . . . . . . . . = 23 9.2. Informative References . . = . . . . . . . . . . . . . . . . 23
= Appendix A. Relax NG Schema . . . . . . . . . . . . . . . . . . . = 24 Appendix A. Relax NG Schema . . . = . . . . . . . . . . . . . . . . 24
= Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . = 49 Appendix B. Examples . . . . . . = . . . . . . . . . . . . . . . . 49
= B.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . = 49 B.1. Example 1 . . . . . . . . = . . . . . . . . . . . . . . . . 49
= B.1.1. iCalendar Data . . . . . . . . . . . . . . . . . . . . 49 = B.1.1. iCalendar Data . . . . . . . . . . = . . . . . . . . . . 49
= B.1.2. XML Data . . . . . . . . . . . . . . . . . . . . . . . 50 = B.1.2. XML Data . . . . . . . . . . . . . = . . . . . . . . . . 50
= B.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . = 50 B.2. Example 2 . . . . . . . . = . . . . . . . . . . . . . . . . 50
= B.2.1. iCalendar Data . . . . . . . . . . . . . . . . . . . . 51 = B.2.1. iCalendar Data . . . . . . . . . . = . . . . . . . . . . 51
skipping to change at page 18, line 14 = skipping to change at = page 18, line 14
= namespace SHOULD be preserved in the iCalendar representation = using namespace SHOULD be preserved in = the iCalendar representation using
= the "XML" iCalendar property described in Section 4.2. the "XML" iCalendar property described in Section = 4.2.
4.2. = The XML property for iCalendar 4.2. The = XML property for iCalendar
= This section describes an extension property for iCalendar, as = This section describes an extension property = for iCalendar, as
= covered in section 8.2.3 of [RFC5545]. = covered in section 8.2.3 of [RFC5545].
= Property name: XML Property name: = XML
= Purpose: To embed XML-encoded calendar data = in the iCalendar format. Purpose: To = embed extended XML-encoded iCalendar data in the
iCalendar = format.
= Value type: The default value type is "TEXT". The value type can = Value type: The default value type is "TEXT". = The value type can
= also be set to "BINARY" to indicate base64 encoded content. = also be set to "BINARY" to indicate base64 = encoded content.
= Property parameters: IANA, non-standard, inline encoding, and = value Property parameters: IANA, = non-standard, inline encoding, and value
= data type property parameters can be specified on this property. = data type property parameters can be specified = on this property.
= Conformance: The property can appear on any = iCalendar component. Conformance: The property can be = specified multiple times in any
calendar component.
= Description: The value of this property is an = XML element. The "XML" Description: = The value of this property is a single XML = 1.0
= property MUST NOT be used to contain properties that are already = = [W3C.REC-xml-20081126] element. The "XML" property MUST NOT be = used
= defined in iCalendar, or properties that use the = "X-" iCalendar to contain = properties that are already defined in iCalendar. Since
extension property = syntax. Since all elements in the all elements in the = urn:ietf:params:xml:ns:icalendar-2.0 namespace
= urn:ietf:params:xml:ns:icalendar-2.0 namespace convert to a well- convert = to a well-defined iCalendar object, the = elements in this
defined iCalendar object, = the elements in this property MUST NOT be property MUST NOT be in the = urn:ietf:params:xml:ns:icalendar-2.0
= in the urn:ietf:params:xml:ns:icalendar-2.0 namespace. The XML = namespace. The XML element which is the value = of this property MUST
= element which is the value of this property MUST have an XML = have an XML namespace declaration.
= namespace declaration.
= Note that the source XML may contain = characters not allowed in The default value type for this property is "TEXT", and = normal
= iCalendar such as control characters. If = this is the case, then the BACKSLASH escaping rules for that value MUST be = applied. Note that
= XML data MUST be base64 encoded. As required by [RFC5545], the = the source XML can contain characters not allowed in "TEXT" property
= "ENCODING" property parameter MUST be present and set to "BASE64", = values. If this = is the case, then the XML data MUST be base64
= and the "VALUE" property parameter MUST be present and set to = encoded. As required by [RFC5545], the = "ENCODING" property parameter
= "BINARY". MUST be present and set to = "BASE64", and the "VALUE" property
parameter MUST be = present and set to "BINARY".
= There can be more than one "XML" property present = for a given The ordering of = "XML" properties is not preserved in the conversion
iCalendar object. The = ordering of "XML" properties is not preserved between xCal and iCalendar.
= in the conversion between xCal and iCalendar.
= Format definition: This property is defined by the following = Format definition: This property is defined by = the following
= notation: notation:
= xml =3D "XML" xmlparam ( ":" text ) / xml =3D "XML" xmlparam ( ":" text ) /
= ( (
= ";" "ENCODING" "=3D" "BASE64" ";" "ENCODING" "=3D" "BASE64"
= ";" "VALUE" "=3D" "BINARY" = ";" "VALUE" "=3D" "BINARY"
= ":" binary = ":" binary
= ) )
= CRLF = CRLF
= xmlparam =3D *(";" other-param) = xmlparam =3D *(";" other-param)
= Example: The following is an example of an iCalendar = event with a Example: The = following is an example of a location embedded in KML
= location embedded in KML markup inside the "XML" property. = markup inside the "XML" property.
= BEGIN:VCALENDAR XML:<kml xmlns=3D"http://www.opengis.net/kml/2.2">\n
= CALSCALE:GREGORIAN <Document>\n
PRODID:-//Example Inc.//Example = Calendar//EN <name>KML = Sample</name>\n
VERSION:2.0 = = <open>1</open>\n
BEGIN:VEVENT = = <description>An incomplete example of a KML docum
= DTSTAMP:20080205T191224Z ent - used as an = example!</description>\n
DTSTART:20081006 = = </kml>
SUMMARY:Planning = meeting
= UID:4088E990AD89CB3DBB484909
= XML:<kml xmlns=3D"http://www.opengis.net/kml/2.2">...</kml>=
END:VEVENT =
END:VCALENDAR =
5. = Handling Unrecognized Properties or Parameters 5. Handling Unrecognized Properties or Parameters
In = iCalendar, properties have a default value type specified by their = In iCalendar, properties have a default value = type specified by their
= definition, e.g. "SUMMARY"'s value type is "TEXT" and = "DURATION"'s definition, e.g. = "SUMMARY"'s value type is "TEXT" and "DURATION"'s
is = "DURATION". When a property uses its default value type, the = is "DURATION". When a property uses its = default value type, the
= "VALUE" property parameter does not need to be specified on the = "VALUE" property parameter does not need to be = specified on the
= property. property.
= When new properties are defined or "X-" properties used, an = When new properties are defined or "X-" = properties used, an
skipping to change at page 23, line 44 = skipping to change at = page 23, line 37
= [RFC4648] Josefsson, S., "The Base16, = Base32, [RFC4648] = Josefsson, S., "The Base16, Base32,
= and Base64 Data Encodings", RFC 4648, = and Base64 Data = Encodings", RFC 4648,
= October 2006. October 2006.
= [RFC5545] Desruisseaux, B., "Internet = [RFC5545] Desruisseaux, = B., "Internet
= Calendaring and Scheduling Core = Calendaring and = Scheduling Core
= Object Specification (iCalendar)", = Object = Specification (iCalendar)",
= RFC 5545, September 2009. RFC 5545, September = 2009.
[W3C.REC-xml-20081126] Paoli, J., Yergeau, F., = Bray, T.,
Sperberg-McQueen, C., = and E. Maler,
"Extensible Markup = Language (XML) 1.0
(Fifth Edition)", World = Wide Web
Consortium = Recommendation REC-xml-
20081126, November = 2008, <http://
= www.w3.org/TR/2008/REC-xml-20081126>.
=
9.2. = Informative References 9.2. Informative = References
= [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML = [W3C.REC-xmlschema-2-20041028] Biron, P. and = A. Malhotra, "XML
= Schema Part 2: Datatypes Second = Schema Part 2: = Datatypes Second
= Edition", World Wide Web Consortium R = Edition", World = Wide Web Consortium R
= ecommendation REC-xmlschema-2- = ecommendation = REC-xmlschema-2-
= 20041028, October 2004, <http:// = 20041028, = October 2004, <http://
= www.w3.org/TR/2004/ = www.w3.org/TR/2004/
= REC-xmlschema-2-20041028>. = = REC-xmlschema-2-20041028>.
skipping to change at page 28, line 47 = skipping to change at = page 29, line 4
= pattern-date =3D xsd:string { = pattern-date =3D xsd:string {
= pattern =3D "\d\d\d\d-\d\d-\d\d" = pattern =3D "\d\d\d\d-\d\d-\d\d"
= } }
= value-date =3D element date { = value-date =3D element date {
= pattern-date pattern-date
= } }
# = 3.3.5 DATE-TIME # 3.3.5 = DATE-TIME
=
= pattern-date-time =3D xsd:string { = pattern-date-time =3D xsd:string {
= pattern =3D "\d\d\d\d-\d\d-\d\dT\d\d-\d\d-\d\dZ?" = pattern =3D "\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\dZ?"
= } }
=
= value-date-time =3D element date-time { = value-date-time =3D element date-time {
= pattern-date-time = pattern-date-time
= } }
# = 3.3.6 DURATION # 3.3.6 = DURATION
= pattern-duration =3D xsd:string { = pattern-duration =3D xsd:string {
= pattern =3D "[+\-]?P(\d+W)|(\d+D)?" = pattern =3D "[+\-]?P(\d+W)|(\d+D)?"
= ~ "(T(\d+H(\d+M)?(\d+S)?)|" = ~ "(T(\d+H(\d+M)?(\d+S)?)|"
= ~ "(\d+M(\d+S)?)|" = ~ "(\d+M(\d+S)?)|"
skipping to change at page 55, line 10 = skipping to change at = page 55, line 10
= </vevent> = </vevent>
= </components> = </components>
= </vcalendar> = </vcalendar>
= </icalendar> = </icalendar>
Appendix C. Change History (to be removed prior to = publication as an Appendix C. Change = History (to be removed prior to publication as an
= RFC) RFC)
= Changes in -10: Changes in = -10:
1. Fixed date-time schema pattern.
2. Tweaked XML property definition based on expert = review
Changes in -10:
=
1. = IESG: Added more XML schema references in value descriptions. = 1. IESG: Added more XML schema references in = value descriptions.
2. = IESG: Added reference to RFC4648 for base64 definition. 2. IESG: Added reference to RFC4648 for base64 = definition.
3. = IESG: Rephrased various uses of "optional". 3. IESG: Rephrased various uses of "optional".
4. = IESG: Clarified round-tripping design consideration. 4. IESG: Clarified round-tripping design = consideration.
5. = IESG: Use "As an example" rather than "non-normative" for tables. = 5. IESG: Use "As an example" rather than = "non-normative" for tables.
 End of changes. 18 change blocks. 
42 lines changed or = deleted 52 lines changed or = added

This html = diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--==========C32029A1482AA24E6B9A==========-- From cyrus@daboo.name Fri May 27 10:38:44 2011 Return-Path: X-Original-To: icalendar@ietfa.amsl.com Delivered-To: icalendar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F32E0843 for ; Fri, 27 May 2011 10:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.947 X-Spam-Level: X-Spam-Status: No, score=-100.947 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHkiWJdkPOZ2 for ; Fri, 27 May 2011 10:38:42 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by ietfa.amsl.com (Postfix) with ESMTP id A8320E080F for ; Fri, 27 May 2011 10:38:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 4373EA86F66; Fri, 27 May 2011 13:38:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8akCmx6w5cX; Fri, 27 May 2011 13:38:35 -0400 (EDT) Received: from [17.151.71.145] (unknown [17.151.76.212]) by daboo.name (Postfix) with ESMTPSA id 1F57BA86F54; Fri, 27 May 2011 13:38:31 -0400 (EDT) Date: Fri, 27 May 2011 10:38:41 -0700 From: Cyrus Daboo To: Bernard Desruisseaux , iana-prot-param-comment@iana.org, icalendar@ietf.org, iana@iana.org Message-ID: <2190AA29EC5D1A553E0BA1D6@wdyn-50-139.arc.nasa.gov> In-Reply-To: <715DF9985D2BFC1C75434F9B@wdyn-50-139.arc.nasa.gov> References: <4DDEF49C.8080108@oracle.com> <715DF9985D2BFC1C75434F9B@wdyn-50-139.arc.nasa.gov> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========BC83B7E32C79057E3C3F==========" Cc: draft-daboo-et-al-icalendar-in-xml@tools.ietf.org, Peter Saint-Andre Subject: Re: [icalendar] [IANA #453987] Registration of new iCalendar property X-BeenThere: icalendar@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: iCalendar List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 17:38:44 -0000 --==========BC83B7E32C79057E3C3F========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=431 Hi Bernard, --On May 27, 2011 7:09:33 AM -0700 Cyrus Daboo wrote: > Please find attached an HTML diff with the proposed changes. Let me know > if this addresses all your comments and I will submit the new draft. Updated diff attached. This addresses one other issue related to clarifying the scope of XML extension elements converted into iCalendar by addition of some text in Section 4.1. -- Cyrus Daboo --==========BC83B7E32C79057E3C3F========== Content-Type: text/html; charset=utf-8; name="rfcdiff.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="rfcdiff.html"; size=62027 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Diff: draft-daboo-et-al-icalendar-in-xml-10.txt - = draft-daboo-et-al-icalendar-in-xml-11.txt=20 =20 =20 =20 =20 =20 <= td class=3D"lineno" valign=3D"top">
< draft-daboo-et-al-icalendar-in-xml-10.txt   draft-daboo-et-al-icalendar-in-xml-11.txt >
Network Working Group = C. Daboo Network Working Group = C. Daboo
Internet-Draft = Apple, Inc. Internet-Draft = Apple, Inc.
Intended status: Standards Track = M. Douglass Intended status: Standards = Track M. Douglass
Expires: November 27, 2011 = RPI Expires: November 28, 2011 = RPI
= S. Lees = = S. Lees
= Microsoft = = Microsoft
= May 26, 2011 = May 27, 2011
= xCal: The XML format for iCalendar xCal: The XML format for = iCalendar
= draft-daboo-et-al-icalendar-in-xml-10 = draft-daboo-et-al-icalendar-in-xml-11
Abstract Abstract
= This specification defines "xCal", an XML format for iCalendar = data. This specification defines = "xCal", an XML format for iCalendar data.
Status of This Memo Status = of This Memo
= This Internet-Draft is submitted in full conformance with the = This Internet-Draft is submitted in full = conformance with the
= provisions of BCP 78 and BCP 79. = provisions of BCP 78 and BCP 79.
= Internet-Drafts are working documents of the Internet Engineering = Internet-Drafts are working documents of the = Internet Engineering
= Task Force (IETF). Note that other groups may also distribute = Task Force (IETF). Note that other groups may = also distribute
= working documents as Internet-Drafts. The list of current = Internet- working documents as = Internet-Drafts. The list of current Internet-
= Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at = http://datatracker.ietf.org/drafts/current/.
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
= and may be updated, replaced, or obsoleted by other documents at = any and may be updated, replaced, or = obsoleted by other documents at any
= time. It is inappropriate to use Internet-Drafts as reference = time. It is inappropriate to use = Internet-Drafts as reference
= material or to cite them other than as "work in progress." = material or to cite them other than as "work in = progress."
= This Internet-Draft will expire on November 27, 2011. This = Internet-Draft will expire on November 28, = 2011.
Copyright Notice Copyright = Notice
= Copyright (c) 2011 IETF Trust and the persons identified as the = Copyright (c) 2011 IETF Trust and the persons = identified as the
= document authors. All rights reserved. = document authors. All rights reserved.
= This document is subject to BCP 78 and the IETF Trust's Legal = This document is subject to BCP 78 and the IETF = Trust's Legal
= Provisions Relating to IETF Documents = Provisions Relating to IETF Documents
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://trustee.ietf.org/license-info) in = effect on the date of
= publication of this document. Please review these documents = publication of this document. Please review = these documents
skipping to change at page 2, line 40 = skipping to change at = page 2, line 40
= 3.6.10. Recurrence Rule (RFC5545 section 3.3.10) . . . . . . . 15 = 3.6.10. Recurrence Rule (RFC5545 section = 3.3.10) . . . . . . . 15
= 3.6.11. Text (RFC5545 section 3.3.11) . . . . . . . . . . . . 16 = 3.6.11. Text (RFC5545 section 3.3.11) . . = . . . . . . . . . . 16
= 3.6.12. Time (RFC5545 section 3.3.12) . . . . . . . . . . . . 16 = 3.6.12. Time (RFC5545 section 3.3.12) . . = . . . . . . . . . . 16
= 3.6.13. URI (RFC5545 section 3.3.13) . . . . . . . . . . . . . 16 = 3.6.13. URI (RFC5545 section 3.3.13) . . . = . . . . . . . . . . 16
= 3.6.14. UTC Offset (RFC5545 section 3.3.14) . . . . . . . . . 16 = 3.6.14. UTC Offset (RFC5545 section 3.3.14) = . . . . . . . . . 16
= 3.7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . = 17 3.7. Extensions . . . . . . . . = . . . . . . . . . . . . . . . . 17
4. = Converting from xCal into iCalendar . . . . . . . . . . . . . 17 = 4. Converting from xCal into iCalendar . . . = . . . . . . . . . . 17
= 4.1. Converting XML Extensions into iCalendar . . . . . . . . . = 17 4.1. Converting XML Extensions = into iCalendar . . . . . . . . . 17
= 4.2. The XML property for iCalendar . . . . . . . . . . . . . . = 18 4.2. The XML property for = iCalendar . . . . . . . . . . . . . . 18
5. = Handling Unrecognized Properties or Parameters . . . . . . . . 19 = 5. Handling Unrecognized Properties or = Parameters . . . . . . . . 19
= 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. = Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 = 7. IANA Considerations . . . . . . . . . . . = . . . . . . . . . . 21
= 7.1. Namespace Registration . . . . . . . . . . . . . . . . . . = 21 7.1. Namespace Registration . . = . . . . . . . . . . . . . . . . 21
= 7.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . . = 21 7.2. Media Type . . . . . . . . = . . . . . . . . . . . . . . . . 21
= 7.3. iCalendar Property Registrations . . . . . . . . . . . . . = 22 7.3. iCalendar Property = Registrations . . . . . . . . . . . . . 22
= 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 8. = Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. = References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 = 9. References . . . . . . . . . . . . . . . . = . . . . . . . . . . 23
= 9.1. Normative References . . . . . . . . . . . . . . . . . . . = 23 9.1. Normative References . . . = . . . . . . . . . . . . . . . . 23
= 9.2. Informative References . . . . . . . . . . . . . . . . . . = 23 9.2. Informative References . . = . . . . . . . . . . . . . . . . 23
= Appendix A. Relax NG Schema . . . . . . . . . . . . . . . . . . . = 24 Appendix A. Relax NG Schema . . . = . . . . . . . . . . . . . . . . 24
= Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . = 49 Appendix B. Examples . . . . . . = . . . . . . . . . . . . . . . . 49
= B.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . = 49 B.1. Example 1 . . . . . . . . = . . . . . . . . . . . . . . . . 49
= B.1.1. iCalendar Data . . . . . . . . . . . . . . . . . . . . 49 = B.1.1. iCalendar Data . . . . . . . . . . = . . . . . . . . . . 49
= B.1.2. XML Data . . . . . . . . . . . . . . . . . . . . . . . 50 = B.1.2. XML Data . . . . . . . . . . . . . = . . . . . . . . . . 50
= B.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . = 50 B.2. Example 2 . . . . . . . . = . . . . . . . . . . . . . . . . 50
= B.2.1. iCalendar Data . . . . . . . . . . . . . . . . . . . . 51 = B.2.1. iCalendar Data . . . . . . . . . . = . . . . . . . . . . 51
skipping to change at page 18, line 5 = skipping to change at = page 18, line 5
= depending on whether the extensions are in the iCalendar XML = depending on whether the extensions are in the = iCalendar XML
= namespace, or in an external namespace. = namespace, or in an external namespace.
= Extensions that are part of the iCalendar XML namespace MUST have = Extensions that are part of the iCalendar XML = namespace MUST have
= element names that begin with "x-", and will be converted back to = the element names that begin with = "x-", and will be converted back to the
= equivalent extension property in iCalendar. For example, the = "x-foo" equivalent extension property = in iCalendar. For example, the "x-foo"
= element will convert to the "X-FOO" iCalendar property. element will convert to the "X-FOO" iCalendar = property.
= Extensions that are in a namespace other than the iCalendar XML = Extensions that are in a namespace other than = the iCalendar XML
= namespace SHOULD be preserved in the iCalendar representation = using namespace SHOULD be preserved in = the iCalendar representation using
= the "XML" iCalendar property described in Section 4.2. the "XML" iCalendar property described in Section 4.2. = Only those
extension elements that are immediate child elements of = the IC:
properties element are converted, any others are = ignored.
4.2. = The XML property for iCalendar 4.2. The = XML property for iCalendar
= This section describes an extension property for iCalendar, as = This section describes an extension property = for iCalendar, as
= covered in section 8.2.3 of [RFC5545]. = covered in section 8.2.3 of [RFC5545].
= Property name: XML Property name: = XML
= Purpose: To embed XML-encoded calendar data = in the iCalendar format. Purpose: To = embed extended XML-encoded iCalendar data in the
iCalendar = format.
= Value type: The default value type is "TEXT". The value type can = Value type: The default value type is "TEXT". = The value type can
= also be set to "BINARY" to indicate base64 encoded content. = also be set to "BINARY" to indicate base64 = encoded content.
= Property parameters: IANA, non-standard, inline encoding, and = value Property parameters: IANA, = non-standard, inline encoding, and value
= data type property parameters can be specified on this property. = data type property parameters can be specified = on this property.
= Conformance: The property can appear on any = iCalendar component. Conformance: The property can be = specified multiple times in any
calendar component.
= Description: The value of this property is an = XML element. The "XML" Description: = The value of this property is a single XML = 1.0
= property MUST NOT be used to contain properties that are already = = [W3C.REC-xml-20081126] element. The "XML" property MUST NOT be = used
= defined in iCalendar, or properties that use the = "X-" iCalendar to contain = properties that are already defined in iCalendar. Since
extension property = syntax. Since all elements in the all elements in the = urn:ietf:params:xml:ns:icalendar-2.0 namespace
= urn:ietf:params:xml:ns:icalendar-2.0 namespace convert to a well- convert = to a well-defined iCalendar object, the = elements in this
defined iCalendar object, = the elements in this property MUST NOT be property MUST NOT be in the = urn:ietf:params:xml:ns:icalendar-2.0
= in the urn:ietf:params:xml:ns:icalendar-2.0 namespace. The XML = namespace. The XML element which is the value = of this property MUST
= element which is the value of this property MUST have an XML = have an XML namespace declaration.
= namespace declaration.
= Note that the source XML may contain = characters not allowed in The default value type for this property is "TEXT", and = normal
= iCalendar such as control characters. If = this is the case, then the BACKSLASH escaping rules for that value MUST be = applied. Note that
= XML data MUST be base64 encoded. As required by [RFC5545], the = the source XML can contain characters not allowed in "TEXT" property
= "ENCODING" property parameter MUST be present and set to "BASE64", = values. If this = is the case, then the XML data MUST be base64
= and the "VALUE" property parameter MUST be present and set to = encoded. As required by [RFC5545], the = "ENCODING" property parameter
= "BINARY". MUST be present and set to = "BASE64", and the "VALUE" property
parameter MUST be = present and set to "BINARY".
= There can be more than one "XML" property present = for a given The ordering of = "XML" properties is not preserved in the conversion
iCalendar object. The = ordering of "XML" properties is not preserved between xCal and iCalendar.
= in the conversion between xCal and iCalendar.
= Format definition: This property is defined by the following = Format definition: This property is defined by = the following
= notation: notation:
= xml =3D "XML" xmlparam ( ":" text ) / xml =3D "XML" xmlparam ( ":" text ) /
= ( (
= ";" "ENCODING" "=3D" "BASE64" ";" "ENCODING" "=3D" "BASE64"
= ";" "VALUE" "=3D" "BINARY" = ";" "VALUE" "=3D" "BINARY"
= ":" binary = ":" binary
= ) )
= CRLF = CRLF
= xmlparam =3D *(";" other-param) = xmlparam =3D *(";" other-param)
= Example: The following is an example of an iCalendar = event with a Example: The = following is an example of a location embedded in KML
= location embedded in KML markup inside the "XML" property. = markup inside the "XML" property.
= BEGIN:VCALENDAR XML:<kml xmlns=3D"http://www.opengis.net/kml/2.2">\n
= CALSCALE:GREGORIAN <Document>\n
PRODID:-//Example Inc.//Example = Calendar//EN <name>KML = Sample</name>\n
VERSION:2.0 = = <open>1</open>\n
BEGIN:VEVENT = = <description>An incomplete example of a KML docum
= DTSTAMP:20080205T191224Z ent - used as an = example!</description>\n
DTSTART:20081006 = = </kml>
SUMMARY:Planning = meeting
= UID:4088E990AD89CB3DBB484909
= XML:<kml xmlns=3D"http://www.opengis.net/kml/2.2">...</kml>=
END:VEVENT =
END:VCALENDAR =
5. = Handling Unrecognized Properties or Parameters 5. Handling Unrecognized Properties or Parameters
In = iCalendar, properties have a default value type specified by their = In iCalendar, properties have a default value = type specified by their
= definition, e.g. "SUMMARY"'s value type is "TEXT" and = "DURATION"'s definition, e.g. = "SUMMARY"'s value type is "TEXT" and "DURATION"'s
is = "DURATION". When a property uses its default value type, the = is "DURATION". When a property uses its = default value type, the
= "VALUE" property parameter does not need to be specified on the = "VALUE" property parameter does not need to be = specified on the
= property. property.
= When new properties are defined or "X-" properties used, an = When new properties are defined or "X-" = properties used, an
skipping to change at page 23, line 44 = skipping to change at = page 23, line 37
= [RFC4648] Josefsson, S., "The Base16, = Base32, [RFC4648] = Josefsson, S., "The Base16, Base32,
= and Base64 Data Encodings", RFC 4648, = and Base64 Data = Encodings", RFC 4648,
= October 2006. October 2006.
= [RFC5545] Desruisseaux, B., "Internet = [RFC5545] Desruisseaux, = B., "Internet
= Calendaring and Scheduling Core = Calendaring and = Scheduling Core
= Object Specification (iCalendar)", = Object = Specification (iCalendar)",
= RFC 5545, September 2009. RFC 5545, September = 2009.
[W3C.REC-xml-20081126] Paoli, J., Yergeau, F., = Bray, T.,
Sperberg-McQueen, C., = and E. Maler,
"Extensible Markup = Language (XML) 1.0
(Fifth Edition)", World = Wide Web
Consortium = Recommendation REC-xml-
20081126, November = 2008, <http://
= www.w3.org/TR/2008/REC-xml-20081126>.
=
9.2. = Informative References 9.2. Informative = References
= [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML = [W3C.REC-xmlschema-2-20041028] Biron, P. and = A. Malhotra, "XML
= Schema Part 2: Datatypes Second = Schema Part 2: = Datatypes Second
= Edition", World Wide Web Consortium R = Edition", World = Wide Web Consortium R
= ecommendation REC-xmlschema-2- = ecommendation = REC-xmlschema-2-
= 20041028, October 2004, <http:// = 20041028, = October 2004, <http://
= www.w3.org/TR/2004/ = www.w3.org/TR/2004/
= REC-xmlschema-2-20041028>. = = REC-xmlschema-2-20041028>.
skipping to change at page 28, line 47 = skipping to change at = page 29, line 4
= pattern-date =3D xsd:string { = pattern-date =3D xsd:string {
= pattern =3D "\d\d\d\d-\d\d-\d\d" = pattern =3D "\d\d\d\d-\d\d-\d\d"
= } }
= value-date =3D element date { = value-date =3D element date {
= pattern-date pattern-date
= } }
# = 3.3.5 DATE-TIME # 3.3.5 = DATE-TIME
=
= pattern-date-time =3D xsd:string { = pattern-date-time =3D xsd:string {
= pattern =3D "\d\d\d\d-\d\d-\d\dT\d\d-\d\d-\d\dZ?" = pattern =3D "\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\dZ?"
= } }
=
= value-date-time =3D element date-time { = value-date-time =3D element date-time {
= pattern-date-time = pattern-date-time
= } }
# = 3.3.6 DURATION # 3.3.6 = DURATION
= pattern-duration =3D xsd:string { = pattern-duration =3D xsd:string {
= pattern =3D "[+\-]?P(\d+W)|(\d+D)?" = pattern =3D "[+\-]?P(\d+W)|(\d+D)?"
= ~ "(T(\d+H(\d+M)?(\d+S)?)|" = ~ "(T(\d+H(\d+M)?(\d+S)?)|"
= ~ "(\d+M(\d+S)?)|" = ~ "(\d+M(\d+S)?)|"
skipping to change at page 55, line 10 = skipping to change at = page 55, line 10
= </vevent> = </vevent>
= </components> = </components>
= </vcalendar> = </vcalendar>
= </icalendar> = </icalendar>
Appendix C. Change History (to be removed prior to = publication as an Appendix C. Change = History (to be removed prior to publication as an
= RFC) RFC)
= Changes in -10: Changes in = -10:
1. Fixed date-time schema pattern.
2. Tweaked XML property definition based on expert = review
Changes in -10:
=
1. = IESG: Added more XML schema references in value descriptions. = 1. IESG: Added more XML schema references in = value descriptions.
2. = IESG: Added reference to RFC4648 for base64 definition. 2. IESG: Added reference to RFC4648 for base64 = definition.
3. = IESG: Rephrased various uses of "optional". 3. IESG: Rephrased various uses of "optional".
4. = IESG: Clarified round-tripping design consideration. 4. IESG: Clarified round-tripping design = consideration.
5. = IESG: Use "As an example" rather than "non-normative" for tables. = 5. IESG: Use "As an example" rather than = "non-normative" for tables.
 End of changes. 19 change blocks. 
43 lines changed or = deleted 55 lines changed or = added

This html = diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--==========BC83B7E32C79057E3C3F==========-- From stpeter@stpeter.im Thu May 26 14:25:40 2011 Return-Path: X-Original-To: icalendar@ietfa.amsl.com Delivered-To: icalendar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49E2E06E1 for ; Thu, 26 May 2011 14:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.608 X-Spam-Level: X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpN+7p65sZMj for ; Thu, 26 May 2011 14:25:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CB4CCE0694 for ; Thu, 26 May 2011 14:25:39 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BFC6C40046; Thu, 26 May 2011 15:25:38 -0600 (MDT) Message-ID: <4DDEC551.9040503@stpeter.im> Date: Thu, 26 May 2011 15:25:37 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Cyrus Daboo References: In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000305030604070609060006" X-Mailman-Approved-At: Fri, 27 May 2011 10:54:59 -0700 Cc: icalendar@ietf.org, iana@iana.org Subject: Re: [icalendar] Registration of new iCalendar property X-BeenThere: icalendar@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: iCalendar List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 21:25:41 -0000 This is a cryptographically signed message in MIME format. --------------ms000305030604070609060006 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/23/11 5:20 PM, Cyrus Daboo wrote: > Hi, > As per the requirements of the iCalendar IANA registration procedures I= > am requesting approval of a new iCalendar property registration. This > property is being registered by draft-daboo-et-al-icalendar-in-xml-09. > In particular, Section 7.3 lists the new items and the section where it= s > template is defined. >=20 > Note: I am one of the designated expert reviewers for this registry but= > will recuse myself since I am a co-author of this document. That seems appropriate. We'll await Bernard's review. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000305030604070609060006 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUy NjIxMjUzN1owIwYJKoZIhvcNAQkEMRYEFLykRVX+jqNrWz5Fx/3s5bOi9IddMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAa00XkBvjcTEBS2cVDJxvYFSmDy/kAf8V5/IlzhN/GrKFQVnRNgKzGY2GD XxhuYjwK1JAfT+/Sjbc/hTJYOVnVhsoFh1zfscr6P2TQESG14gffIS5favlXyOzEzDM0+f4u Ir47rfo9a7NfoSteA57G/Ha+99kfAEI2I9mkJQK11Jqf1M//sSmjLkiw54UUI1bYkvRvFcEk IupyydonpmF5wZR9oE40R+sKaPs+2IvYiGnstl7nFv2NDM6NdkBugk483vVtndmr9HxhOz2B Lvg3RKNk2et1sN1XPMpIe0PIHMrrATkTsH8ak8ZGhNMAc8kYaB0AItJ4UeEsLTndjl5zAAAA AAAA --------------ms000305030604070609060006--