Subject: Re: [ietf-caldav] draft-desruisseaux-caldav-sched-06: 3.5.1.2. Attendee overrides
From: Bernard Desruisseaux <[email-masked]>
To: Mark Cockfield <[email-masked]>
Cc: IETF <[email-masked]>
Date: Fri, 28 Nov 2008 13:33:17 -0500
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

Yes. Indeed.

Mark Cockfield wrote:
> It states:
> 
>     "... The Organizer will then need to incorporate any new overridden
>     instances into the matching scheduling object resource to ensure
>     that the Attendee's participation status is accurately recorded for
>     all recurrence instances."
> 
> 
> Is it reasonable to assume that if the organizer’s SCHEDULE-AGENT is not 
> specified or SERVER that this “incorporate” will be handled be the server?
> 
> Regards,
> 
> Mark
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Wed, 26 Nov 2008 22:21:38 -0500
From: Mark Cockfield <[email-masked]>
To: IETF <[email-masked]>
Subject: [ietf-caldav] draft-desruisseaux-caldav-sched-06: 3.5.1.2. Attendee overrides

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3310582899_1819034
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

It states:

> "... The Organizer will then need to incorporate any new overridden insta=
nces
> into the matching scheduling object resource to ensure that the Attendee'=
s
> participation status is accurately recorded for all recurrence instances.=
"

Is it reasonable to assume that if the organizer=B9s SCHEDULE-AGENT is not
specified or SERVER that this =B3incorporate=B2 will be handled be the server?

Regards,

Mark

--B_3310582899_1819034
Content-type: text/html; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>draft-desruisseaux-caldav-sched-06: 3.5.1.2. Attendee overrides</TIT=
LE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'>It states:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0p=
x'>&quot;... The Organizer will then need to incorporate any new overridden =
instances into the matching scheduling object resource to ensure that the At=
tendee's participation status is accurately recorded for all recurrence inst=
ances.&quot;<BR>
</SPAN></FONT></BLOCKQUOTE><SPAN STYLE=3D'font-size:12.0px'><FONT FACE=3D"Genev=
a"><BR>
</FONT><FONT FACE=3D"Verdana">Is it reasonable to</FONT><FONT FACE=3D"Geneva"> =
assume that if the organizer&#8217;s SCHEDULE-AGENT is not specified or SERV=
ER that this &#8220;incorporate&#8221; will be handled be the server?<BR>
<BR>
Regards,<BR>
<BR>
Mark</FONT></SPAN>
</BODY>
</HTML>

--B_3310582899_1819034--

From: "Tim Hare" <[email-masked]>
To: "'Julian Reschke'" <[email-masked]>, "'Cyrus Daboo'" <[email-masked]>
Date: Sat, 22 Nov 2008 14:36:35 -0500
Cc: "'Emsley, I \(Iain\)'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-caldav] Group access for scheduling events and trying to limit calendaring spam

Don't forget to check each group that you're about to expand at level 'n' to
see if you've already expanded it at level 'n-m' or you will end up
expanding groups forever (or until your process is killed). It's not
impossible for group 'A' to contain group 'B' which contains group 'C' which
contains group 'A' in many systems, since many UAs don't check for that kind
of thing. 

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Julian Reschke
Sent: Saturday, November 22, 2008 8:23 AM
To: Cyrus Daboo
Cc: Emsley, I (Iain); [email-masked]
Subject: Re: [ietf-caldav] Group access for scheduling events and trying to
limit calendaring spam

Cyrus Daboo wrote:
> ...
> The DAV:group-membership property on a user's principal will tell you 
> what groups that user is a member of. In theory you could then 
> PROPFIND that group principal to get the DAV:group-memberset property 
> which tells you which principals are a member of that group. One issue 
> with that is that a member of a group could itself be a group, so you 
> would want to further expand that. However, the only way to know 
> whether a principal is a group is to PROPFIND the principal. What this 
> means is that if you want to do a "depth infinity" group expansion, 
> the client ends up having to potentially do lots of PROPFINDs 
> depending on how groups are setup at a site. This can be a scalability 
> problem if clients have to do that a lot. A better option would be a 
> new property or REPORT that does the "depth infinity" expansion for 
> the client (i.e. one request instead of many - shifting more of the load
to the server).
> ...

The DAV:expand-property report at least gives you Depth 1, right?

> ...

BR, Julian

_______________________________________________
ietf-caldav mailing list -- [email-masked] See
http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Sat, 22 Nov 2008 14:22:42 +0100
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: "Emsley, I \(Iain\)" <[email-masked]>, [email-masked]
Subject: Re: [ietf-caldav] Group access for scheduling events and trying to limit calendaring spam

Cyrus Daboo wrote:
> ...
> The DAV:group-membership property on a user's principal will tell you what 
> groups that user is a member of. In theory you could then PROPFIND that 
> group principal to get the DAV:group-memberset property which tells you 
> which principals are a member of that group. One issue with that is that a 
> member of a group could itself be a group, so you would want to further 
> expand that. However, the only way to know whether a principal is a group 
> is to PROPFIND the principal. What this means is that if you want to do a 
> "depth infinity" group expansion, the client ends up having to potentially 
> do lots of PROPFINDs depending on how groups are setup at a site. This can 
> be a scalability problem if clients have to do that a lot. A better option 
> would be a new property or REPORT that does the "depth infinity" expansion 
> for the client (i.e. one request instead of many - shifting more of the 
> load to the server).
> ...

The DAV:expand-property report at least gives you Depth 1, right?

> ...

BR, Julian

Date: Mon, 17 Nov 2008 09:40:07 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Mark Cockfield <[email-masked]>
Cc: IETF <[email-masked]>
Subject: Re: [ietf-caldav] Deprecated Request Headers

Hi Mark,

You are correct.

All recipients are attendees, but attendees are not necessarily 
recipients (see SCHEDULE-AGENT paramter).

Cheers,
Bernard

Mark Cockfield wrote:
> Greetings,
> 
> Forgive me for being a bit behind, I've been working off of CalDAV
> Scheduling-04 and just discovered I was two version behind. Anyway, I
> noticed that the originator and recipient request headers are now absent but
> am unable to find any mention of deprecation. Am I correct in assuming they
> have been dismissed?
> 
> Regards,
> 
> Mark
> 
> _______________________________________________
> ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> 

From: [email-masked]
To: [email-masked]
Date: Sat, 15 Nov 2008 14:11:05 +0100
Subject: [ietf-caldav] implementing scheduling in caldav4j
Reply-To: [email-masked]

I wanted to implement caldav sched 06 in caldav4j but don't know if the =
draft is stable enough.. Peace, Rob 

Date: Sat, 15 Nov 2008 00:29:59 -0500
From: Mark Cockfield <[email-masked]>
To: IETF <[email-masked]>
Subject: [ietf-caldav] Deprecated Request Headers

Greetings,

Forgive me for being a bit behind, I've been working off of CalDAV
Scheduling-04 and just discovered I was two version behind. Anyway, I
noticed that the originator and recipient request headers are now absent but
am unable to find any mention of deprecation. Am I correct in assuming they
have been dismissed?

Regards,

Mark

Date: Fri, 14 Nov 2008 13:12:58 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Arnaud Quillaud <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-caldav] typo in expanded mode example ?

Thanks to Cyrus, our working copy of rfc4791bis is now accessible here:

http://caldav.calconnect.org/caldavfiles/

Here's a link to the issue you brought up:

http://caldav.calconnect.org/caldavfiles/files/draft-desruisseaux-rfc4791bis.changes.html#rfc.issue.example-missing-utc-designator

Cheers,
Bernard

Bernard Desruisseaux wrote:
> Hi Arnaud,
> 
> Yes, this is a typo.
> 
> Jari Urpalainen had actually reported it to me back in March 2007 along 
> with other typos.
> 
> I'll try to publish our working copy of rfc4791bis on the web...
> 
> Thanks,
> Bernard
> 
> Arnaud Quillaud wrote:
>> Hello, the expanded mode example at
>>
>> http://tools.ietf.org/html/rfc4791#section-7.8.3
>>
>> shows all DTSTART and RECURRENCE-ID without a final "Z".
>>
>> In the meantime, the definition of the expanded mode states that "
>>
>> Date and local
>>       time with reference to time zone information MUST be converted
>>       into date with UTC time.
>>
>> ".
>> (http://tools.ietf.org/html/rfc4791#section-9.6.5)
>>
>> So do we have a typo in the example ?
>>
>> Thanks,
>>
>> Arnaud Q
>> _______________________________________________
>> ietf-caldav mailing list -- [email-masked]
>> See http://ietf.webdav.org/caldav/ for more CalDAV resources
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>>
> 
> 

Date: Fri, 14 Nov 2008 09:51:36 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Arnaud Quillaud <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-caldav] typo in expanded mode example ?

Hi Arnaud,

Yes, this is a typo.

Jari Urpalainen had actually reported it to me back in March 2007 along 
with other typos.

I'll try to publish our working copy of rfc4791bis on the web...

Thanks,
Bernard

Arnaud Quillaud wrote:
> Hello, the expanded mode example at
> 
> http://tools.ietf.org/html/rfc4791#section-7.8.3
> 
> shows all DTSTART and RECURRENCE-ID without a final "Z".
> 
> In the meantime, the definition of the expanded mode states that "
> 
> Date and local
>       time with reference to time zone information MUST be converted
>       into date with UTC time.
> 
> ".
> (http://tools.ietf.org/html/rfc4791#section-9.6.5)
> 
> So do we have a typo in the example ?
> 
> Thanks,
> 
> Arnaud Q
> _______________________________________________
> ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> 

From: Roberto Polli <[email-masked]>
Organization: Babel s.r.l
To: [email-masked]
Date: Fri, 14 Nov 2008 15:24:16 +0100
Subject: Re: [ietf-caldav] typo in expanded mode example ?

Alle venerd=EC 14 novembre 2008, Arnaud Quillaud ha scritto:
> So do we have a typo in the example ?
*to me* it seems so: dates are in UTC time, but no "Z"

I can't find anything in the response to address that it was an "expanded"=
=20
request, nor TZ info.

how can I understand they're in Z and not floating-tz ?

Peace, R.

=2D-=20

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo=20
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene=20
notizia a mezzo e-mail. Vi sollecitiamo altres=EC a distruggere il messaggi=
o=20
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto=
=20
della legge in materia di protezione dei dati personali."

Date: Fri, 14 Nov 2008 11:11:12 +0100
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [ietf-caldav] typo in expanded mode example ?

Hello, the expanded mode example at

http://tools.ietf.org/html/rfc4791#section-7.8.3

shows all DTSTART and RECURRENCE-ID without a final "Z".

In the meantime, the definition of the expanded mode states that "

Date and local
      time with reference to time zone information MUST be converted
      into date with UTC time.

".
(http://tools.ietf.org/html/rfc4791#section-9.6.5)

So do we have a typo in the example ?

Thanks,

Arnaud Q

Content-class: urn:content-classes:message
Date: Thu, 13 Nov 2008 12:00:53 -0000
From: "Emsley, I (Iain)" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-caldav] Group access for scheduling events and trying to	limit calendaring spam

Date: Wed, 12 Nov 2008 10:41:43 -0500
From: Cyrus Daboo <[email-masked]>
To: "Emsley, I (Iain)" <[email-masked]>, [email-masked]
Subject: Re: [ietf-caldav] Group access for scheduling events and trying to	limit calendaring spam

Hi I,

--On November 12, 2008 2:51:50 PM +0000 "Emsley, I (Iain)"=20
<[email-masked]> wrote:

> I=E2=80=99ve been looking at the implementations of allowing a user  to
> schedule to mailing list groups, to which they are subscribed, within
> calDAV but which also allows for a user to schedule a meeting with
> individuals who may or may not be in the system.
>
>
> I looked up the DAV:current-user-privilege-set in RFC3447 following the
> comments in RFC4791 about calDAV building on the webDAV access privileges
> which would appear to answer the first issue: i.e. it could be used to
> query the directory of groups to build a list of groups to which the user
> has access at that moment and create an address book for scheduling in
> the UI.

The DAV:group-membership property on a user's principal will tell you what=20
groups that user is a member of. In theory you could then PROPFIND that=20
group principal to get the DAV:group-memberset property which tells you=20
which principals are a member of that group. One issue with that is that a=20
member of a group could itself be a group, so you would want to further=20
expand that. However, the only way to know whether a principal is a group=20
is to PROPFIND the principal. What this means is that if you want to do a=20
"depth infinity" group expansion, the client ends up having to potentially=20
do lots of PROPFINDs depending on how groups are setup at a site. This can=20
be a scalability problem if clients have to do that a lot. A better option=20
would be a new property or REPORT that does the "depth infinity" expansion=20
for the client (i.e. one request instead of many - shifting more of the=20
load to the server).

The other thing to bear in mind is that not all servers will expose the=20
full principal hierarchy to users. Indeed, some will only allow the user to =

read their own principal and not those of others for privacy reasons etc.=20
In that case the client has to rely on external directory services to=20
figure out group memberships etc.

Once you do get information about a group, the next problem is how=20
scheduling with that group works. At present we are trying to avoid=20
defining the specific of this in the caldav scheduling spec simply because=20
there are many different ways in which groups can be handled, e.g.:

- client expands membership explicitly into separate ATTENDEEs
- server expands membership explicitly by re-writing group ATTENDEE into=20
separate ATTENDEEs
- group ATTENDEE remains as only attendee, but server takes care of sending =

scheduling message to each member as an ATTENDEE

There are also several different semantics for groups: e.g. a "help desk"=20
group might require one and only one member of that group to actually be=20
scheduled, whereas a "company board" group might require a specific number=20
(quorum) to attendee etc.

Because of all these complex semantics of groups, we want to avoid saying=20
anything about them in the base caldav scheduling spec, but to follow that=20
up with an extension that describes how different types of groups can be=20
handled.

>
>
> However I also need to be able to allow the user to schedule with an
> individual, for example user A wants to schedule to their list which is a
> committee but they also have an invited expert Person B, but block any
> access to either accidental or malicious attempts to schedule to lists
> that User A is not part of.  In this case I would want to email the group
> email (probably by expanding the group into its individual parts
> (dependent on size) and return an anonymised version of the user address
> as well as Person B=E2=80=99s user address) and send the invitation that =
way.

So the other issue you have is with "anonymizing" the scheduling messages.=20
This can take several forms (e.g. obfuscating the calendar user addresses=20
of other attendees, stripping out the ATTENDEE properties of other=20
attendees etc). There is no formal way to do that. In the past we had=20
talked about the concept of "Bcc" attendees, i.e. attendees whose ATTENDEE=20
property is only sent in scheduling messages to that attendee and not to=20
any one else (similar to Bcc in email). That would take care of one mode of =

operation. The obfuscation approach would probably best be handled by a=20
parameter that the Organizer could put on their copy of the event that=20
tells the server (or other clients) to obfuscate attendee addresses when=20
sending to other attendees.

Of course in each of these cases the server/client ends up having to send a =

lot more scheduling messages as each attendee will end up having to have=20
their own modified copy.

For the specific example you give above of wanting to invite one "outsider" =

a better solution would be to simply create a separate event just for that=20
attendee and then manage the "internal" and "external" events together.=20
That won't scale well when there are a lot of "outsiders" each of which has =

to have their own view - but if there is just an "internal" event and an=20
"external" event to manage, that should not be too hard for now, at least=20
until we can come up with extensions to help out.

--=20
Cyrus Daboo

Content-class: urn:content-classes:message
Date: Wed, 12 Nov 2008 14:51:50 -0000
From: "Emsley, I (Iain)" <[email-masked]>
To: <[email-masked]>
Subject: [ietf-caldav] Group access for scheduling events and trying to limit calendaring spam

This is a multi-part message in MIME format.

------_=_NextPart_001_01C944D6.31CB3650
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I've been looking at the implementations of allowing a user  to schedule
to mailing list groups, to which they are subscribed, within calDAV but
which also allows for a user to schedule a meeting with individuals who
may or may not be in the system.=20

=20

I looked up the DAV:current-user-privilege-set in RFC3447 following the
comments in RFC4791 about calDAV building on the webDAV access
privileges which would appear to answer the first issue: i.e. it could
be used to query the directory of groups to build a list of groups to
which the user has access at that moment and create an address book for
scheduling in the UI.=20
=20
However I also need to be able to allow the user to schedule with an
individual, for example user A wants to schedule to their list which is
a committee but they also have an invited expert Person B, but block any
access to either accidental or malicious attempts to schedule to lists
that User A is not part of.  In this case I would want to email the
group email (probably by expanding the group into its individual parts
(dependent on size) and return an anonymised version of the user address
as well as Person B's user address) and send the invitation that way.
=20
I know that each group, in this case, is limited to one domain so is it
permissible to block access to any scheduling attempt NOT in the UI
directory for the individual which is addressed from that domain and
return an appropriate error to the user? =20
=20
I don't see any thing in the RFC that says not but I would appreciate
comments as I try to find a way of using calDAV for groups without
falling outside of calDAV.=20
=20
Thanks,=20
=20
Iain

=20

Iain Emsley

=20

Support Analyst

JISCmail: www.jiscmail.ac.uk <http://www.jiscmail.ac.uk>=20

Mailtalk: www.mailtalk.ac.uk <http://www.mailtalk.ac.uk>=20

=20

-- =0AScanned by iCritical.=0A

------_=_NextPart_001_01C944D6.31CB3650
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-GB link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>I&#8217;ve been looking at the implementations of =
allowing a
user &nbsp;to schedule to mailing list groups, to which they are =
subscribed,
within calDAV but which also allows for a user to schedule a meeting =
with
individuals who may or may not be in the system. <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<pre><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>I looked =
up the DAV:current-user-privilege-set in RFC3447 following the comments =
in RFC4791 about calDAV building on the webDAV access privileges which =
would appear to answer the first issue: i.e. it could be used to query =
the directory of groups to build a list of groups to which the user has =
access at that moment and create an address book for scheduling in the =
UI. <o:p></o:p></span></pre><pre><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></pre><pre><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>However I =
also need to be able to allow the user to schedule with an individual, =
for example user A wants to schedule to their list which is a committee =
but they also have an invited expert Person B, but block any access to =
either accidental or malicious attempts to schedule to lists that User A =
is not part of. &nbsp;In this case I would want to email the group email =
(probably by expanding the group into its individual parts (dependent on =
size) and return an anonymised version of the user address as well as =
Person B&#8217;s user address) and send the invitation that =
way.<o:p></o:p></span></pre><pre><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></pre><pre><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>I know =
that each group, in this case, is limited to one domain so is it =
permissible to block access to any scheduling attempt NOT in the UI =
directory for the individual which is addressed from that domain and =
return an appropriate error to the user?&nbsp; =
<o:p></o:p></span></pre><pre><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></pre><pre><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>I =
don&#8217;t see any thing in the RFC that says not but I would =
appreciate comments as I try to find a way of using calDAV for groups =
without falling outside of calDAV. <o:p></o:p></span></pre><pre><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></pre><pre><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Thanks, =
<o:p></o:p></span></pre><pre><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></pre><pre><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Iain</span>=
<span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></pre>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Iain
Emsley</span><span style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Times =
New Roman","serif"'>&nbsp;<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Support
Analyst</span><span style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>JISCmail:
<a href=3D"http://www.jiscmail.ac.uk"><span =
style=3D'color:blue'>www.jiscmail.ac.uk</span></a></span><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Mailtalk:
<a href=3D"http://www.mailtalk.ac.uk"><span =
style=3D'color:blue'>www.mailtalk.ac.uk</span></a></span><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Times =
New Roman","serif"'>&nbsp;</span><o:p></o:p></p>

</div>

<br>=
<p>-- =0A<BR>Scanned by iCritical.=0A</p>
<br>=
</body>

</html>

------_=_NextPart_001_01C944D6.31CB3650--

Date: Tue, 11 Nov 2008 13:08:41 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [ietf-caldav] I-D Action:draft-desruisseaux-caldav-sched-06.txt (fwd)

--==========CBE85158E32A162E57C9==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Sorry, I forgot to forward this to the list last week when the draft got 
posted.

------------ Forwarded Message -----------
Date: November 3, 2008 1:15:02 PM -0800
From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-desruisseaux-caldav-sched-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : CalDAV Scheduling Extensions to WebDAV
	Author(s)       : C. Daboo, B. Desruisseaux
	Filename        : draft-desruisseaux-caldav-sched-06.txt
	Pages           : 57
	Date            : 2008-11-03

This document defines extensions to the CalDAV calendar-access
feature to specify a standard way of performing scheduling
transactions with iCalendar-based calendar components.  This document
defines the "calendar-auto-schedule" feature of CalDAV.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

--==========CBE85158E32A162E57C9==========
Content-Type: message/rfc822;
 name="I-D Action:draft-desruisseaux-caldav-sched-06.txt "

From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-desruisseaux-caldav-sched-06.txt 
Date: Mon,  3 Nov 2008 13:15:02 -0800 (PST)
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : CalDAV Scheduling Extensions to WebDAV
	Author(s)       : C. Daboo, B. Desruisseaux
	Filename        : draft-desruisseaux-caldav-sched-06.txt
	Pages           : 57
	Date            : 2008-11-03

This document defines extensions to the CalDAV calendar-access
feature to specify a standard way of performing scheduling
transactions with iCalendar-based calendar components.  This document
defines the "calendar-auto-schedule" feature of CalDAV.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-desruisseaux-caldav-sched-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

--==========CBE85158E32A162E57C9==========--

Content-class: urn:content-classes:message
Date: Tue, 4 Nov 2008 20:06:57 +0100
From: "Daniel Gomez Brito" <[email-masked]>
To: <[email-masked]>
Subject: Re: [ietf-caldav] Question about recurring tasks.

Hello:

> -----Mensaje original-----
> De: [email-masked] [mailto:ietf-caldav-
> [email-masked]] En nombre de Roberto Polli
> Enviado el: lunes, 03 de noviembre de 2008 21:01
> Para: [email-masked]
> Asunto: Re: [ietf-caldav] Question about recurring tasks.
>=20
> Alle luned=EC 03 novembre 2008, Bernard Desruisseaux ha scritto:
> > BTW, I just found the following info in the Calsify Working Group
> > Minutes for July 12, 2006:
> >
> > http://www.ietf.org/proceedings/06jul/minutes/calsify.txt
>=20
> imho the issue arise when an vcs (maybe on mobile) is converted to ics.
>=20
> Peace, R.
>=20

I asked my colleague how the task entered our system:
He created the task in Outlook 2003 and then synchronized via a Funambol pl=
ugin, so there is at least one conversion involved (perhaps two).

Anyway, the task was created for testing purposes and after reading Bernard=
's clarification, I don't think it's worth to bother dealing with the relax=
ed implementation.

Thanks everyone for your help.
Regards.

______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la=20
Informacion siendo para uso exclusivo del destinatario, quedando=20
prohibida su divulgacion copia o distribucion a terceros sin la=20
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje=20
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado.=
=20
Gracias por su colaboracion.
______________________
This message including any attachments may contain confidential=20
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.
______________________

From: Roberto Polli <[email-masked]>
Organization: Babel s.r.l
To: [email-masked]
Date: Mon, 3 Nov 2008 21:01:07 +0100
Subject: Re: [ietf-caldav] Question about recurring tasks.

Alle luned=EC 03 novembre 2008, Bernard Desruisseaux ha scritto:
> BTW, I just found the following info in the Calsify Working Group
> Minutes for July 12, 2006:
>
> http://www.ietf.org/proceedings/06jul/minutes/calsify.txt

imho the issue arise when an vcs (maybe on mobile) is converted to ics.

Peace, R.

=2D-=20

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo=20
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene=20
notizia a mezzo e-mail. Vi sollecitiamo altres=EC a distruggere il messaggi=
o=20
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto=
=20
della legge in materia di protezione dei dati personali."

Date: Mon, 03 Nov 2008 11:03:29 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Daniel Gomez Brito <[email-masked]>
Cc: IETF Calsify <[email-masked]>, [email-masked]
Subject: Re: [ietf-caldav] Question about recurring tasks.

BTW, I just found the following info in the Calsify Working Group 
Minutes for July 12, 2006:

http://www.ietf.org/proceedings/06jul/minutes/calsify.txt

 > 7 Is DTSTART required in VTODO and VJOURNAL components when the RRULE
 > or EXRULE properties are defined in those components?
 >
 > Cyrus floated another idea that in the case of VTODO, perhaps the
 > recurrence could use the DUE property. Bernard suggested that perhaps
 > in the absence of DTSTART, it could default to DUE.
 >
 > Lisa pointed out that this needs more discussion beyond the room,
 > because different apps behave differently.
 >
 > In the end, some agreement that it's enough to clarify that for
 > recurring VTODOs, VJOURNALs, etc., they MUST specify DTSTART even
 > if it's otherwise optional.
 >
 > AI: Go forward with above clarification

The clarification (issue 24) was made in the section that covers 
"DTSTART", see:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-09.changes.html#rfc.issue.#issue29+dtstart_in_recur_vtodo_and_vjournal

I believe similar text should appear in the "RRULE" section as well...

Cheers,
Bernard

Bernard Desruisseaux wrote:
> Hi Daniel,
> 
> In section 4.8.5.4 Recurrence Rule of RFC 2445 it says:
> 
>  > The recurrence set is generated by considering the initial "DTSTART"
>  > property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE"
>  > properties contained within the iCalendar object.
> 
> As such, the "DTSTART" should always be specified in a calendar 
> component that also specify the "RRULE" property.
> 
> That being said, this should probably be stated more clearly in rfc2445bis.
> 
> To be very clear, in iCalendar recurrence instances of a recurring 
> "VTODO" are not computed based on the "DUE" property of the master 
> component.
> 
> So to answer your question, a strict implementation should handle a 
> recurring task with no "DTSTART" as an invalid "VTODO" component, and a 
> relax implementation could probably fix the invalid "VTODO" component by 
> adding the missing "DTSTART" property with the same value as "DUE".
> 
> Cheers,
> Bernard
> 
> Daniel Gomez Brito wrote:
>> Hello:
>>
>>  
>>
>> What’s the proper way to treat a recurring task with no dtstart property?
>>
>> It doesn’t make sense to me but it seems there’s a bunch of portable 
>> devices that let you build something like this:
>>
>>  
>>
>> BEGIN:VCALENDAR
>>
>> VERSION:2.0
>>
>> PRODID:-//Test//Ver 1.0.0 //ES
>>
>> BEGIN:VTODO
>>
>> SUMMARY:cxcx
>>
>> DESCRIPTION:xcx
>>
>> CATEGORIES:
>>
>> CLASS:PUBLIC
>>
>> DUE;VALUE=DATE:20081030
>>
>> PRIORITY:5
>>
>> ORGANIZER:
>>
>> PERCENT-COMPLETE:0
>>
>> STATUS:NEEDS-ACTION
>>
>> RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TH
>>
>> X-FUNAMBOL-FOLDER:DEFAULT_FOLDER
>>
>> X-FUNAMBOL-ALLDAY:1
>>
>> UID:20081028T082036Z-2
>>
>> DTSTAMP:20081028T082035Z
>>
>> END:VTODO
>>
>> END:VCALENDAR
>>
>>  
>>
>> Regards.
>>
>>  
>>
>> ------------------------------------------------------------------------
>> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede 
>> contener información clasificada por su emisor como confidencial en el 
>> marco de su Sistema de Gestión de Seguridad de la Información siendo 
>> para uso exclusivo del destinatario, quedando prohibida su divulgación 
>> copia o distribución a terceros sin la autorización expresa del 
>> remitente. Si Vd. ha recibido este mensaje erróneamente, se ruega lo 
>> notifique al remitente y proceda a su borrado. Gracias por su 
>> colaboración.
>> ------------------------------------------------------------------------
>> This message including any attachments may contain confidential 
>> information, according to our Information Security Management System, 
>> and intended solely for a specific individual to whom they are 
>> addressed. Any unauthorised copy, disclosure or distribution of this 
>> message is strictly forbidden. If you have received this transmission 
>> in error, please notify the sender immediately and delete it.
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> ietf-caldav mailing list -- [email-masked]
>> See http://ietf.webdav.org/caldav/ for more CalDAV resources
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> 
> 

Date: Mon, 03 Nov 2008 10:46:20 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Daniel Gomez Brito <[email-masked]>
Cc: IETF Calsify <[email-masked]>, [email-masked]
Subject: Re: [ietf-caldav] Question about recurring tasks.

Hi Daniel,

In section 4.8.5.4 Recurrence Rule of RFC 2445 it says:

 > The recurrence set is generated by considering the initial "DTSTART"
 > property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE"
 > properties contained within the iCalendar object.

As such, the "DTSTART" should always be specified in a calendar 
component that also specify the "RRULE" property.

That being said, this should probably be stated more clearly in rfc2445bis.

To be very clear, in iCalendar recurrence instances of a recurring 
"VTODO" are not computed based on the "DUE" property of the master 
component.

So to answer your question, a strict implementation should handle a 
recurring task with no "DTSTART" as an invalid "VTODO" component, and a 
relax implementation could probably fix the invalid "VTODO" component by 
adding the missing "DTSTART" property with the same value as "DUE".

Cheers,
Bernard

Daniel Gomez Brito wrote:
> Hello:
> 
>  
> 
> What’s the proper way to treat a recurring task with no dtstart property?
> 
> It doesn’t make sense to me but it seems there’s a bunch of portable 
> devices that let you build something like this:
> 
>  
> 
> BEGIN:VCALENDAR
> 
> VERSION:2.0
> 
> PRODID:-//Test//Ver 1.0.0 //ES
> 
> BEGIN:VTODO
> 
> SUMMARY:cxcx
> 
> DESCRIPTION:xcx
> 
> CATEGORIES:
> 
> CLASS:PUBLIC
> 
> DUE;VALUE=DATE:20081030
> 
> PRIORITY:5
> 
> ORGANIZER:
> 
> PERCENT-COMPLETE:0
> 
> STATUS:NEEDS-ACTION
> 
> RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TH
> 
> X-FUNAMBOL-FOLDER:DEFAULT_FOLDER
> 
> X-FUNAMBOL-ALLDAY:1
> 
> UID:20081028T082036Z-2
> 
> DTSTAMP:20081028T082035Z
> 
> END:VTODO
> 
> END:VCALENDAR
> 
>  
> 
> Regards.
> 
>  
> 
> ------------------------------------------------------------------------
> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede 
> contener información clasificada por su emisor como confidencial en el 
> marco de su Sistema de Gestión de Seguridad de la Información siendo 
> para uso exclusivo del destinatario, quedando prohibida su divulgación 
> copia o distribución a terceros sin la autorización expresa del 
> remitente. Si Vd. ha recibido este mensaje erróneamente, se ruega lo 
> notifique al remitente y proceda a su borrado. Gracias por su colaboración.
> ------------------------------------------------------------------------
> This message including any attachments may contain confidential 
> information, according to our Information Security Management System, 
> and intended solely for a specific individual to whom they are 
> addressed. Any unauthorised copy, disclosure or distribution of this 
> message is strictly forbidden. If you have received this transmission in 
> error, please notify the sender immediately and delete it.
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Roberto Polli <[email-masked]>
Organization: Babel s.r.l
To: [email-masked]
Date: Mon, 3 Nov 2008 15:24:37 +0100
Subject: Re: [ietf-caldav] Question about recurring tasks.

Alle luned=EC 03 novembre 2008, Daniel Gomez Brito ha scritto:
> ... RRULES defines a set of prior
> instances. Is this right?
it could be. One question about how the event is generated.
If it's created by a mobile in x-vcalendar, then converted by funambol serv=
er=20
in icalendar, there could be a conversion issue ..

Peace, R:

=2D-=20

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo=20
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene=20
notizia a mezzo e-mail. Vi sollecitiamo altres=EC a distruggere il messaggi=
o=20
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto=
=20
della legge in materia di protezione dei dati personali."

Content-class: urn:content-classes:message
Date: Mon, 3 Nov 2008 15:08:22 +0100
From: "Daniel Gomez Brito" <[email-masked]>
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [ietf-caldav] Question about recurring tasks.

Hello Helge,

If I have not misunderstood both your reply and Tim's, if the task is
missing DTSTART I should consider the instance defined in the VTODO
component as the last one and therefore RRULES defines a set of prior
instances. Is this right?

Regards.

______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la=20
Informacion siendo para uso exclusivo del destinatario, quedando=20
prohibida su divulgacion copia o distribucion a terceros sin la=20
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje=20
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado.=
=20
Gracias por su colaboracion.
______________________
This message including any attachments may contain confidential=20
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.
______________________

Content-class: urn:content-classes:message
Date: Mon, 3 Nov 2008 14:45:25 +0100
From: "Daniel Gomez Brito" <[email-masked]>
To: "Roberto Polli" <[email-masked]>, <[email-masked]>
Subject: Re: [ietf-caldav] Question about recurring tasks.

Hello Roberto,=20

> -----Mensaje original-----
> De: [email-masked] [mailto:ietf-caldav-
> [email-masked]] En nombre de Roberto Polli
> Enviado el: lunes, 03 de noviembre de 2008 13:52
> Para: [email-masked]
> Asunto: Re: [ietf-caldav] Question about recurring tasks.
>=20
> Alle luned=EC 03 novembre 2008, Daniel Gomez Brito ha scritto:
> > My problem comes from the server side. Suppose I want to search all the
> > tasks within a time range, how should I expand them if they are
> > recurrent but lack a DTSTART property?
> I'm not sure, but resources without DTSTART/END should be always reported
> by
> REPORT.
>=20
> Am I wrong?

You are right, if the VTODO lacks DTSTART, DURATION, DUE, CREATED AND COMPL=
ETED properties, it should be reported.
But this is a different scenario; the task is recurrent and has a DUE prope=
rty.
>=20
> - which caldav server?
Custom calendaring backend.

> - which client?
>=20
The task was created by a colleague, I'll ask him.

> Peace, R.
> R.
>=20
>=20
>=20
> --
>=20
> Roberto Polli
> Babel S.r.l. - http://www.babel.it
> Tel. +39.06.91801075 - fax +39.06.91612446
> P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
>=20
> "Il seguente messaggio contiene informazioni riservate. Qualora questo
> messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene
> notizia a mezzo e-mail. Vi sollecitiamo altres=EC a distruggere il messag=
gio
> erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del
> rispetto
> della legge in materia di protezione dei dati personali."
>=20
> _______________________________________________
> ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la=20
Informacion siendo para uso exclusivo del destinatario, quedando=20
prohibida su divulgacion copia o distribucion a terceros sin la=20
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje=20
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado.=
=20
Gracias por su colaboracion.
______________________
This message including any attachments may contain confidential=20
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.
______________________

From: Helge Hess <[email-masked]>
To: CalDAV DevList <[email-masked]>
Date: Mon, 3 Nov 2008 13:53:59 +0100
Subject: Re: [ietf-caldav] Question about recurring tasks.

On 03.11.2008, at 13:44, Daniel Gomez Brito wrote:
> My problem comes from the server side. Suppose I want to search all  
> the
> tasks within a time range, how should I expand them if they are
> recurrent but lack a DTSTART property?

Same approach. You expand them as if the DTSTART would be the  
startdate of the queried timerange.

The only thing which seems invalid to me (not sure what the spec  
says), is no-DTSTART but a COUNT in the RRULE.

Greets,
   Helge
-- 
Helge Hess
http://zideone.com/

From: Roberto Polli <[email-masked]>
Organization: Babel s.r.l
To: [email-masked]
Date: Mon, 3 Nov 2008 13:52:11 +0100
Subject: Re: [ietf-caldav] Question about recurring tasks.

Alle luned=EC 03 novembre 2008, Daniel Gomez Brito ha scritto:
> My problem comes from the server side. Suppose I want to search all the
> tasks within a time range, how should I expand them if they are
> recurrent but lack a DTSTART property?
I'm not sure, but resources without DTSTART/END should be always reported b=
y=20
REPORT.

Am I wrong?

=2D which caldav server?
=2D which client?

Peace, R.
R.

=2D-=20

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo=20
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene=20
notizia a mezzo e-mail. Vi sollecitiamo altres=EC a distruggere il messaggi=
o=20
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto=
=20
della legge in materia di protezione dei dati personali."

From: "Tim Hare" <[email-masked]>
To: "'CalDAV DevList'" <[email-masked]>
Date: Mon, 3 Nov 2008 07:47:50 -0500
Subject: Re: [ietf-caldav] Question about recurring tasks.

I would suggest that the client put it / show it on the calendar with a
calculated start date of the first date, satisfying the recurrence rule,
that occurs after the DTSTAMP property, unless you want to make it
retroactive to the earliest dates in the calendar.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Helge Hess
Sent: Monday, November 03, 2008 6:23 AM
To: CalDAV DevList
Subject: Re: [ietf-caldav] Question about recurring tasks.

On 03.11.2008, at 11:56, Daniel Gomez Brito wrote:
> What's the proper way to treat a recurring task with no dtstart 
> property?

In which context? In a client application?

> It doesn't make sense to me but it seems there's a bunch of portable 
> devices that let you build something like this:

Well, I assume the device will show the task as open on each Thursday,
unless there is an exception (with status 'done'). The startdate doesn't
really matter here?

The result with a done task would look something like:
---snip---
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Test//Ver 1.0.0 //ES
BEGIN:VTODO
UID:abc
SUMMARY:cxcx
DESCRIPTION:xcx
CATEGORIES:
CLASS:PUBLIC
DUE;VALUE=DATE:20081030
PRIORITY:5
ORGANIZER:
PERCENT-COMPLETE:0
STATUS:NEEDS-ACTION
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TH
X-FUNAMBOL-FOLDER:DEFAULT_FOLDER
X-FUNAMBOL-ALLDAY:1
UID:20081028T082036Z-2
DTSTAMP:20081028T082035Z
END:VTODO
BEGIN:VTODO
UID:abc
SUMMARY:cxcx
RECURRENCE-ID:2008-10-06
DESCRIPTION:xcx
CATEGORIES:
CLASS:PUBLIC
DUE;VALUE=DATE:20081030
PRIORITY:5
ORGANIZER:
PERCENT-COMPLETE:100
STATUS:DONE
X-FUNAMBOL-FOLDER:DEFAULT_FOLDER
X-FUNAMBOL-ALLDAY:1
UID:20081028T082036Z-2
DTSTAMP:20081028T082035Z
END:VTODO
END:VCALENDAR
---snap---

Didn't check for 100% correctness, but you get the idea ;-)

Greets,
   Helge
--
Helge Hess
http://zideone.com/
_______________________________________________
ietf-caldav mailing list -- [email-masked] See
http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Content-class: urn:content-classes:message
Date: Mon, 3 Nov 2008 13:44:55 +0100
From: "Daniel Gomez Brito" <[email-masked]>
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [ietf-caldav] Question about recurring tasks.

Hello Helge,

> -----Mensaje original-----
> De: [email-masked] [mailto:ietf-caldav-
> [email-masked]] En nombre de Helge Hess
> Enviado el: lunes, 03 de noviembre de 2008 12:23
> Para: CalDAV DevList
> Asunto: Re: [ietf-caldav] Question about recurring tasks.
>=20
> On 03.11.2008, at 11:56, Daniel Gomez Brito wrote:
> > What's the proper way to treat a recurring task with no dtstart
> > property?
>=20
> In which context? In a client application?
>=20

My problem comes from the server side. Suppose I want to search all the
tasks within a time range, how should I expand them if they are
recurrent but lack a DTSTART property?
=20
> > It doesn't make sense to me but it seems there's a bunch of portable
> > devices that let you build something like this:
>=20
> Well, I assume the device will show the task as open on each Thursday,
> unless there is an exception (with status 'done'). The startdate
> doesn't really matter here?
>=20
> The result with a done task would look something like:
> ---snip---
> BEGIN:VCALENDAR
> VERSION:2.0
> PRODID:-//Test//Ver 1.0.0 //ES
> BEGIN:VTODO
> UID:abc
> SUMMARY:cxcx
> DESCRIPTION:xcx
> CATEGORIES:
> CLASS:PUBLIC
> DUE;VALUE=3DDATE:20081030
> PRIORITY:5
> ORGANIZER:
> PERCENT-COMPLETE:0
> STATUS:NEEDS-ACTION
> RRULE:FREQ=3DWEEKLY;INTERVAL=3D1;BYDAY=3DTH
> X-FUNAMBOL-FOLDER:DEFAULT_FOLDER
> X-FUNAMBOL-ALLDAY:1
> UID:20081028T082036Z-2
> DTSTAMP:20081028T082035Z
> END:VTODO
> BEGIN:VTODO
> UID:abc
> SUMMARY:cxcx
> RECURRENCE-ID:2008-10-06
> DESCRIPTION:xcx
> CATEGORIES:
> CLASS:PUBLIC
> DUE;VALUE=3DDATE:20081030
> PRIORITY:5
> ORGANIZER:
> PERCENT-COMPLETE:100
> STATUS:DONE
> X-FUNAMBOL-FOLDER:DEFAULT_FOLDER
> X-FUNAMBOL-ALLDAY:1
> UID:20081028T082036Z-2
> DTSTAMP:20081028T082035Z
> END:VTODO
> END:VCALENDAR
> ---snap---
>=20
> Didn't check for 100% correctness, but you get the idea ;-)
>=20
> Greets,
>    Helge
> --
> Helge Hess
> http://zideone.com/
> _______________________________________________
> ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la=20
Informacion siendo para uso exclusivo del destinatario, quedando=20
prohibida su divulgacion copia o distribucion a terceros sin la=20
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje=20
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado.=
=20
Gracias por su colaboracion.
______________________
This message including any attachments may contain confidential=20
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.
______________________

From: Helge Hess <[email-masked]>
To: CalDAV DevList <[email-masked]>
Date: Mon, 3 Nov 2008 12:22:56 +0100
Subject: Re: [ietf-caldav] Question about recurring tasks.

On 03.11.2008, at 11:56, Daniel Gomez Brito wrote:
> What=92s the proper way to treat a recurring task with no dtstart =20
> property?

In which context? In a client application?

> It doesn=92t make sense to me but it seems there=92s a bunch of =
portable =20
> devices that let you build something like this:

Well, I assume the device will show the task as open on each Thursday, =20=

unless there is an exception (with status 'done'). The startdate =20
doesn't really matter here?

The result with a done task would look something like:
---snip---
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Test//Ver 1.0.0 //ES
BEGIN:VTODO
UID:abc
SUMMARY:cxcx
DESCRIPTION:xcx
CATEGORIES:
CLASS:PUBLIC
DUE;VALUE=3DDATE:20081030
PRIORITY:5
ORGANIZER:
PERCENT-COMPLETE:0
STATUS:NEEDS-ACTION
RRULE:FREQ=3DWEEKLY;INTERVAL=3D1;BYDAY=3DTH
X-FUNAMBOL-FOLDER:DEFAULT_FOLDER
X-FUNAMBOL-ALLDAY:1
UID:20081028T082036Z-2
DTSTAMP:20081028T082035Z
END:VTODO
BEGIN:VTODO
UID:abc
SUMMARY:cxcx
RECURRENCE-ID:2008-10-06
DESCRIPTION:xcx
CATEGORIES:
CLASS:PUBLIC
DUE;VALUE=3DDATE:20081030
PRIORITY:5
ORGANIZER:
PERCENT-COMPLETE:100
STATUS:DONE
X-FUNAMBOL-FOLDER:DEFAULT_FOLDER
X-FUNAMBOL-ALLDAY:1
UID:20081028T082036Z-2
DTSTAMP:20081028T082035Z
END:VTODO
END:VCALENDAR
---snap---

Didn't check for 100% correctness, but you get the idea ;-)

Greets,
   Helge
--=20
Helge Hess
http://zideone.com/=

Content-class: urn:content-classes:message
Date: Mon, 3 Nov 2008 11:56:35 +0100
From: "Daniel Gomez Brito" <[email-masked]>
To: <[email-masked]>
Subject: [ietf-caldav] Question about recurring tasks.

This is a multi-part message in MIME format.

------_=_NextPart_001_01C93DA2.D6D8C639
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello:

=20

What's the proper way to treat a recurring task with no dtstart
property?=20

It doesn't make sense to me but it seems there's a bunch of portable
devices that let you build something like this:

=20

BEGIN:VCALENDAR

VERSION:2.0

PRODID:-//Test//Ver 1.0.0 //ES

BEGIN:VTODO

SUMMARY:cxcx

DESCRIPTION:xcx

CATEGORIES:

CLASS:PUBLIC

DUE;VALUE=3DDATE:20081030

PRIORITY:5

ORGANIZER:

PERCENT-COMPLETE:0

STATUS:NEEDS-ACTION

RRULE:FREQ=3DWEEKLY;INTERVAL=3D1;BYDAY=3DTH

X-FUNAMBOL-FOLDER:DEFAULT_FOLDER

X-FUNAMBOL-ALLDAY:1

UID:20081028T082036Z-2

DTSTAMP:20081028T082035Z

END:VTODO

END:VCALENDAR

=20

Regards.

=20

______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la=20
Informacion siendo para uso exclusivo del destinatario, quedando=20
prohibida su divulgacion copia o distribucion a terceros sin la=20
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje=20
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado.=
=20
Gracias por su colaboracion.
______________________
This message including any attachments may contain confidential=20
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.
______________________

------_=_NextPart_001_01C93DA2.D6D8C639
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EstiloCorreo17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DES link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Hello:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>What&#8217;s the proper way to treat a recurring =
task
with no dtstart property? <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>It doesn&#8217;t make sense to me but it seems th=
ere&#8217;s
a bunch of portable devices that let you build something like this:<o:p></o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>BEGIN:VCALENDAR<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>VERSION:2.0<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>PRODID:-//Test//Ver 1.0.0 //ES<o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>BEGIN:VTODO<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>SUMMARY:cxcx<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>DESCRIPTION:xcx<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>CATEGORIES:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>CLASS:PUBLIC<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>DUE;VALUE=3DDATE:20081030<o:p></o:p></span></font=
></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>PRIORITY:5<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>ORGANIZER:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>PERCENT-COMPLETE:0<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>STATUS:NEEDS-ACTION<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>RRULE:FREQ=3DWEEKLY;INTERVAL=3D1;BYDAY=3DTH<o:p><=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>X-FUNAMBOL-FOLDER:DEFAULT_FOLDER<o:p></o:p></span=
></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>X-FUNAMBOL-ALLDAY:1<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>UID:20081028T082036Z-2<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>DTSTAMP:20081028T082035Z<o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>END:VTODO<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>END:VCALENDAR<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>Regards.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

<p><font size=3D1 color=3Dgray face=3DAri
al><span style=3D'font-size:
8.0pt;font-family:Arial;color:gray'><hr size=3D2 width=3D'100%' align=3Dcen=
ter>
Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener
informaci=F3n clasificada por su emisor como confidencial en el marco de su
Sistema de Gesti=F3n de Seguridad de la Informaci=F3n siendo para uso exclu=
sivo
del destinatario, quedando prohibida su divulgaci=F3n copia o distribuci=F3=
n a
terceros sin la autorizaci=F3n expresa del remitente. Si Vd. ha recibido es=
te
mensaje err=F3neamente, se ruega lo notifique al remitente y proceda a su b=
orrado.
</span></font><font size=3D1 color=3Dgray face=3DArial><span lang=3DEN-GB
style=3D'font-size:8.0pt;font-family:Arial;color:gray'>Gracias por su
colaboraci=F3n.<o:p></o:p></span></font>
<font size=3D1 color=3Dgray face=3DArial><span style=3D'font-size:
8.0pt;font-family:Arial;color:gray'><hr size=3D2 width=3D'100%' align=3Dcen=
ter>
This message including any attachments may contain confidential information,
according to our Information Security Management System, and intended solely
for a specific individual to whom they are addressed. Any unauthorised copy,
disclosure or distribution of this message is strictly forbidden. If you ha=
ve
received this transmission in error, please notify the sender immediately a=
nd delete it.
</span></font>
<hr size=3D2 width=3D'100%' align=3Dcenter></p>
</body>

</html>

------_=_NextPart_001_01C93DA2.D6D8C639--