[Ietf-calsify] UTC

[Doug at Royer.com (Doug Royer)]

Helge Hess wrote:

>
> As mentioned before this issue might be resolved by putting rrules 
> into an extension to a core spec, so that we have a base spec which 
> only requires UTC which of course would be a huge simplification.

I agree. For protocols like CAP and CalDAV, that works. For iMIP there 
may be
no way in advance to know if the recipient will ignore or understand any 
extensions.

So I think that the base set needs to be 100% compatible at the iMIP level.

Perhaps we need to add an optional property that can be added to iCAL 
objects
that indicate the extensions supported by the sender. Then the recipient
will know how it can reply. And then the recipient also includes this
extension property so then the originator may then track which recipient
supports which features.  Such as:

    EXTENSIONS: XXXX,YYYY,ZZZZ

where XXXX, YYYY, and ZZZZ are RFC numbers that describe extensions.
This would be placed in the VCALENDAR objects. Then the recipient
of the object would know that the sender supports RFC-XXXX, RFC-YYYY,
and RFC-ZZZZ extensions.

Vendor specific extensions could be handled with a vendor specific
property such as X-EXTENSIONS that could follow the vendor specifications.

If the EXTENSIONS property is absent, then the sender only supports
RFC-'calsify-basic' which I think needs to be compatible with iCAL
and would not include the rrule properties.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040930/c88cd692/smime.bin
From TimHare at comcast.net  Thu Sep 30 20:50:39 2004
From: TimHare at comcast.net ([e-mail])
Date: Thu Sep 30 20:54:29 2004
Subject: [Ietf-calsify] UTC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

I'd hate to give up the idea of some form of recurrence too easily. For the 
most common use cases - like weekly and monthly events - recurrence is a 
convenient and efficient shorthand. Perhaps we can adopt the following 
simplifications:

1. All components exchanged or published use UTC for date/time properties.
2. A new component is defined, VRECUR (or a better name) is defined for use 
only locally, which has simple properties for recurring events.
3. VRECUR does not allow infinite repetition
4. Components have a recurrence ID (RID - something I think was proposed 
before?) which can be null.
4. VRECUR dates and times use floating time to eliminate daylight savings 
time problems.
5. When exchanging VRECUR components, send the VRECUR with RID and 
beginning time converted to UTC, then convert to VEVENT/VTODO/etc. and UTC 
and send those, with the same RID.
6. Recipients can accept and store the VRECUR if capable, and ignore the 
events with that RID, or ignore the VRECUR and accept the events.
7. "Exchanging" also applies to publishing to a file.

This is a minor amount of overhead compared to just exchanging the 
individual events, yet allows both ends to use the more compact way of 
storing the recurring events if desired.  It leaves conversion from UTC to 
local time as a presentation problem. We would still have to define the 
"simple properties" for VRECUR. I think we would need to concentrate on the 
few use cases which are used by the majority of people. There's probably an 
80/20 rule there somewhere. Does anyone have a way to gather statistics on 
recurrence definitions? For example, where I work we use Notes and I'd bet 
80% of recurrence is "weekly".

If this seems like it's not solving the problem or introducing new ones, 
then I'd agree to "just UTC with no RRULEs in the base spec", and putting 
RRULEs elsewhere.


At 02:45 PM 9/30/04, Doug Royer wrote:


>Helge Hess wrote:
>
>>
>>As mentioned before this issue might be resolved by putting rrules into 
>>an extension to a core spec, so that we have a base spec which only 
>>requires UTC which of course would be a huge simplification.
>
>I agree. For protocols like CAP and CalDAV, that works. For iMIP there may be
>no way in advance to know if the recipient will ignore or understand any 
>extensions.
>
>So I think that the base set needs to be 100% compatible at the iMIP level.
>
>Perhaps we need to add an optional property that can be added to iCAL objects
>that indicate the extensions supported by the sender. Then the recipient
>will know how it can reply. And then the recipient also includes this
>extension property so then the originator may then track which recipient
>supports which features.  Such as:
>
>    EXTENSIONS: XXXX,YYYY,ZZZZ
>
>where XXXX, YYYY, and ZZZZ are RFC numbers that describe extensions.
>This would be placed in the VCALENDAR objects. Then the recipient
>of the object would know that the sender supports RFC-XXXX, RFC-YYYY,
>and RFC-ZZZZ extensions.
>
>Vendor specific extensions could be handled with a vendor specific
>property such as X-EXTENSIONS that could follow the vendor specifications.
>
>If the EXTENSIONS property is absent, then the sender only supports
>RFC-'calsify-basic' which I think needs to be compatible with iCAL
>and would not include the rrule properties.
>
>--
>
>Doug Royer                     |   http://INET-Consulting.com
>-------------------------------|-----------------------------
>[e-mail]                 | Office: [phone]
>http://Royer.com/People/Doug   | Fax:    [phone]
>                               | Cell:   [phone]
>
>              We Do Standards - You Need Standards
>
>
>
>
>
>_______________________________________________
>Ietf-calsify mailing list
>[e-mail]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i913sQBl025342 for <[e-mail]>; Thu, 30 Sep 2004 20:54:26 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc13) with SMTP id <2004100103542001500o14m7e> (Authid: TimHare); Fri, 1 Oct 2004 03:54:20 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Thu, 30 Sep 2004 23:50:39 -0400
To: [e-mail]
From: [e-mail]
Subject: Re: [Ietf-calsify] UTC
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 01 Oct 2004 03:54:27 -0000

I'd hate to give up the idea of some form of recurrence too easily. For the 
most common use cases - like weekly and monthly events - recurrence is a 
convenient and efficient shorthand. Perhaps we can adopt the following 
simplifications:

1. All components exchanged or published use UTC for date/time properties.
2. A new component is defined, VRECUR (or a better name) is defined for use 
only locally, which has simple properties for recurring events.
3. VRECUR does not allow infinite repetition
4. Components have a recurrence ID (RID - something I think was proposed 
before?) which can be null.
4. VRECUR dates and times use floating time to eliminate daylight savings 
time problems.
5. When exchanging VRECUR components, send the VRECUR with RID and 
beginning time converted to UTC, then convert to VEVENT/VTODO/etc. and UTC 
and send those, with the same RID.
6. Recipients can accept and store the VRECUR if capable, and ignore the 
events with that RID, or ignore the VRECUR and accept the events.
7. "Exchanging" also applies to publishing to a file.

This is a minor amount of overhead compared to just exchanging the 
individual events, yet allows both ends to use the more compact way of 
storing the recurring events if desired.  It leaves conversion from UTC to 
local time as a presentation problem. We would still have to define the 
"simple properties" for VRECUR. I think we would need to concentrate on the 
few use cases which are used by the majority of people. There's probably an 
80/20 rule there somewhere. Does anyone have a way to gather statistics on 
recurrence definitions? For example, where I work we use Notes and I'd bet 
80% of recurrence is "weekly".

If this seems like it's not solving the problem or introducing new ones, 
then I'd agree to "just UTC with no RRULEs in the base spec", and putting 
RRULEs elsewhere.


At 02:45 PM 9/30/04, Doug Royer wrote:


>Helge Hess wrote:
>
>>
>>As mentioned before this issue might be resolved by putting rrules into 
>>an extension to a core spec, so that we have a base spec which only 
>>requires UTC which of course would be a huge simplification.
>
>I agree. For protocols like CAP and CalDAV, that works. For iMIP there may be
>no way in advance to know if the recipient will ignore or understand any 
>extensions.
>
>So I think that the base set needs to be 100% compatible at the iMIP level.
>
>Perhaps we need to add an optional property that can be added to iCAL objects
>that indicate the extensions supported by the sender. Then the recipient
>will know how it can reply. And then the recipient also includes this
>extension property so then the originator may then track which recipient
>supports which features.  Such as:
>
>    EXTENSIONS: XXXX,YYYY,ZZZZ
>
>where XXXX, YYYY, and ZZZZ are RFC numbers that describe extensions.
>This would be placed in the VCALENDAR objects. Then the recipient
>of the object would know that the sender supports RFC-XXXX, RFC-YYYY,
>and RFC-ZZZZ extensions.
>
>Vendor specific extensions could be handled with a vendor specific
>property such as X-EXTENSIONS that could follow the vendor specifications.
>
>If the EXTENSIONS property is absent, then the sender only supports
>RFC-'calsify-basic' which I think needs to be compatible with iCAL
>and would not include the rrule properties.
>
>--
>
>Doug Royer                     |   http://INET-Consulting.com
>-------------------------------|-----------------------------
>[e-mail]                 | Office: [phone]
>http://Royer.com/People/Doug   | Fax:    [phone]
>                               | Cell:   [phone]
>
>              We Do Standards - You Need Standards
>
>
>
>
>
>_______________________________________________
>Ietf-calsify mailing list
>[e-mail]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8UIjEBm020818 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Thu, 30 Sep 2004 11:45:15 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8UIj3mH032150 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 30 Sep 2004 11:45:04 -0700
Message-ID: <[e-mail]>
Date: Thu, 30 Sep 2004 12:45:02 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] UTC
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090703020303010105070100"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2004 18:45:17 -0000

This is a cryptographically signed message in MIME format.

--------------ms090703020303010105070100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Helge Hess wrote:

>
> As mentioned before this issue might be resolved by putting rrules 
> into an extension to a core spec, so that we have a base spec which 
> only requires UTC which of course would be a huge simplification.

I agree. For protocols like CAP and CalDAV, that works. For iMIP there 
may be
no way in advance to know if the recipient will ignore or understand any 
extensions.

So I think that the base set needs to be 100% compatible at the iMIP level.

Perhaps we need to add an optional property that can be added to iCAL 
objects
that indicate the extensions supported by the sender. Then the recipient
will know how it can reply. And then the recipient also includes this
extension property so then the originator may then track which recipient
supports which features.  Such as:

    EXTENSIONS: XXXX,YYYY,ZZZZ

where XXXX, YYYY, and ZZZZ are RFC numbers that describe extensions.
This would be placed in the VCALENDAR objects. Then the recipient
of the object would know that the sender supports RFC-XXXX, RFC-YYYY,
and RFC-ZZZZ extensions.

Vendor specific extensions could be handled with a vendor specific
property such as X-EXTENSIONS that could follow the vendor specifications.

If the EXTENSIONS property is absent, then the sender only supports
RFC-'calsify-basic' which I think needs to be compatible with iCAL
and would not include the rrule properties.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms090703020303010105070100
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTMwMTg0NTAyWjAjBgkqhkiG9w0BCQQxFgQU8S5GiXsVlvaE540PHEOo
P0kEZUUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEASSuLZLIhKZmqpLDYrIFqEh9c60UIl6fIYRnoHq20g51/NErQ0bemB/K+VyPudDBv
314xIsgBWM28jSaLqi8U+2DZ/CLKsgQq0hbkWOqvhRcwSJpzFUrO86jTa8hKc1kwSbWmkMB2
JBwI9yCURqXJsd/mNu6pGhYycgke9fxaZ4/t2ZCufGNyvPrvhTqz1SN7dR64zq/LCFyxTFPY
Rm0RE9ov9wQjnLqvaDXhKhXRY1USyhObBoz52SBMEjLPfBhAOlttJmv74JfxKsV+8hSnRyYT
mjpJZz8l9NFNcVIknAdWLFkkEUyWKF/LJcuW/72o3kjW8bKXnzJySbU62GzTUAAAAAAAAA==
--------------ms090703020303010105070100--



X-Envelope-From: [e-mail]
Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8UHccBm016521 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 30 Sep 2004 10:38:40 -0700
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault <[e-mail]>
Subject: Re: [Ietf-calsify] UTC
Date: Thu, 30 Sep 2004 10:38:30 -0700
To: Helge Hess <[e-mail]>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2004 17:38:43 -0000

Someone could write this up!  Often it takes a solid proposal for 
people to see the full effect of such a major simplification.

Lisa

On Sep 30, 2004, at 10:29 AM, Helge Hess wrote:

> On Sep 30, 2004, at 19:16, Nathaniel Borenstein wrote:
>> Once again, most of the complexities come from RRULES.
>> When you enumerate all the events in a set, it's easy to get the time 
>> right for each.
>> When you try to say it more succinctly, with a rule, everything gets 
>> absurdly complex.
>
> I think everyone can agree with that.
>
>> If everything "on the wire" was specified as sets rather than rules, 
>> we wouldn't need time zones on the wire either.
>
> At the loss of functionality which is widely used, I suppose few will 
> agree with removing rrules completely (would be fine for me though).
>
> As mentioned before this issue might be resolved by putting rrules 
> into an extension to a core spec, so that we have a base spec which 
> only requires UTC which of course would be a huge simplification.
>
> Greets,
>   Helge
> -- 
> http://docs.opengroupware.org/Members/helge/
> OpenGroupware.org
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8UHTuBl015770 for <[e-mail]>; Thu, 30 Sep 2004 10:29:56 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 3E8FF291A05 for <[e-mail]>; Thu, 30 Sep 2004 19:29:39 +0200 (CEST)
Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id D49BC2919CC for <[e-mail]>; Thu, 30 Sep 2004 19:29:38 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] UTC
Date: Thu, 30 Sep 2004 19:29:44 +0200
To: [e-mail]
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2004 17:29:57 -0000

On Sep 30, 2004, at 19:16, Nathaniel Borenstein wrote:
> Once again, most of the complexities come from RRULES.
> When you enumerate all the events in a set, it's easy to get the time 
> right for each.
> When you try to say it more succinctly, with a rule, everything gets 
> absurdly complex.

I think everyone can agree with that.

> If everything "on the wire" was specified as sets rather than rules, 
> we wouldn't need time zones on the wire either.

At the loss of functionality which is widely used, I suppose few will 
agree with removing rrules completely (would be fine for me though).

As mentioned before this issue might be resolved by putting rrules into 
an extension to a core spec, so that we have a base spec which only 
requires UTC which of course would be a huge simplification.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8UHGvBl013541 for <[e-mail]>; Thu, 30 Sep 2004 10:16:57 -0700
Received: from [192.168.0.102] [68.42.70.186] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id A91E1A601F0; Thu, 30 Sep 2004 09:49:34 -0700
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Nathaniel Borenstein <[e-mail]>
Subject: Re: [Ietf-calsify] UTC
Date: Thu, 30 Sep 2004 13:16:45 -0400
To: Helge Hess <[e-mail]>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2004 17:16:58 -0000

On Sep 19, 2004, at 10:56 AM, Helge Hess wrote:

> On Sep 17, 2004, at 4:05, [e-mail] wrote:
>> To me, saying UTC minus 5 hours pretty specifically specifies the 
>> time adjustment - different timezone names might map to the same 
>> offset, but it's the offset that matters.  The name is merely a way 
>> to find the offset when you need to do the calculation.
>
> No. One timezone name maps to various timezone offsets. The obvious 
> second one, as Cyrus already mentioned, is daylight savings.
> If you have a cyclic appointment which happens each monday at 11:00 
> CET, this will be 11:00Z+0100 in winter and 11:00+0200 in summer. So 
> actually the symbolic name is the important thing and the 
> "calculation" we were talking about is not adding the offset, but 
> calculating DSTs.

Once again, most of the complexities come from RRULES.  When you 
enumerate all the events in a set, it's easy to get the time right for 
each.  When you try to say it more succinctly, with a rule, everything 
gets absurdly complex.  If everything "on the wire" was specified as 
sets rather than rules, we wouldn't need time zones on the wire either. 
  -- Nathaniel



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8M3YxBl008883 for <[e-mail]>; Tue, 21 Sep 2004 20:34:59 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc13) with SMTP id <2004092203345201500ehm3ie> (Authid: TimHare); Wed, 22 Sep 2004 03:34:53 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Tue, 21 Sep 2004 23:32:42 -0400
To: [e-mail]
From: [e-mail]
Subject: Re: [Ietf-calsify] Re: charter
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 22 Sep 2004 03:35:00 -0000

Back on the 14th, there was some discussion about coming up with a charter, 
along with some discussion about "How it can be done" versus "How it is 
being done now".  I haven't seen much discussion since, though I have seen 
some more discussion attempting to summarized list issues so far.

Here's my proposal for a mission statement: "to find a set of iCalendar 
objects, and iTip verbs which can be used between any two calendaring 
products/tools and which will provide interoperability between any two 
calendaring products/tools".

To add to the  "How it ... " discussion,  and in conformance with my 
mission statement above, I would propose that even if a particular piece of 
software supports lots of complex interaction between its own clients and 
servers there exists the need to use a simplified interaction with other 
implementations.

Here are the cases I've thought of so far:

A:  Publishing (METHOD: PUBLISH) a file to be picked up by others, 
implementations unknown.
B: Using iTIP methods to interact with others,  in domains other than the 
current one,  implementations unknown.
C: Using iTIP methods to interact with others in the same domain, 
implementation can possibly be assumed.

In case A I would propose all dates be either UTC or floating, and that 
recurrence sets be expanded before publishing into many VEVENTS.

In case B I would propose all dates be UTC,  but the simplest forms of 
RRULEs be used (or not at all).

In case C use whatever features are implemented.

The implementation can determine what to do for each 
attendee/organizer/whatever based on whether the host name of that person 
matches the domain of the implementation - i.e., if I'm scheduling a 
meeting in Lotus Notes and all the attendees have the same host and domain 
name, I can assume they are also using Lotus Notes. If they have the same 
domain name but different host names, I can't make that assumption because 
many companies might have multiple different implementations such as 
Groupwise and Exchange.

Our simplification and interoperability problems come primarily from case 
B. Therefore, the simplest course to me would be to find the "greatest 
common factors" or "least common denominators" between implementations , 
then in a draft document specify that as the interoperability 
specification. We would have a document that described one way to 
interoperate, while we could continue to debate what to include/exclude to 
simplify things. Since, to interoperate, we would probably be describing 
mostly the simpler parts of the current RFCs we'd be unlikely to eliminate 
many of those parts as we reworked things.

When the first Interop report from the Calendaring & Scheduling Consortium 
comes out, we will have another data point to work from, also.


Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8JEuOBl029396 for <[e-mail]>; Sun, 19 Sep 2004 07:56:25 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id CF9342858C0 for <[e-mail]>; Sun, 19 Sep 2004 16:55:46 +0200 (CEST)
Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 7DE982858BA for <[e-mail]>; Sun, 19 Sep 2004 16:55:46 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] UTC
Date: Sun, 19 Sep 2004 16:56:17 +0200
To: [e-mail]
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 19 Sep 2004 14:56:26 -0000

On Sep 17, 2004, at 4:05, [e-mail] wrote:
> To me, saying UTC minus 5 hours pretty specifically specifies the time 
> adjustment - different timezone names might map to the same offset, 
> but it's the offset that matters.  The name is merely a way to find 
> the offset when you need to do the calculation.

No. One timezone name maps to various timezone offsets. The obvious 
second one, as Cyrus already mentioned, is daylight savings.
If you have a cyclic appointment which happens each monday at 11:00 
CET, this will be 11:00Z+0100 in winter and 11:00+0200 in summer. So 
actually the symbolic name is the important thing and the "calculation" 
we were talking about is not adding the offset, but calculating DSTs.

> That said, I still think it is simpler to use UTC for storing and 
> exchanging everything;

If a timezone name would be the same like an offset, that would be 
true. But a timezone name (unfortunately for us ;-) maps to different 
offsets.
Again: this _only_ matters for cyclic appointments. (well, it would 
also matter for Brazil time, but I consider that too obscure, does any 
other country change DST each year?).

Notably this is not just for summer/winter time, the daylight savings 
are decided by the governments and can (and did!) change over the years 
or when political situations change.

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8HHXpBl030379 for <[e-mail]>; Fri, 17 Sep 2004 10:33:52 -0700
Received: from curie.fam.tuwien.ac.at (curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id i8HHXoQ09716 for <[e-mail]>; Fri, 17 Sep 2004 19:33:50 +0200
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] List issues so far.
Date: Fri, 17 Sep 2004 19:33:47 +0200
User-Agent: KMail/1.7
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1242059.rRcZgWYXgS"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Scanned-By: MIMEDefang 2.39
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Sep 2004 17:33:53 -0000

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

>        (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.

Most applications just ignore the seconds. So why should they be required i=
f=20
they are mostly ignored?

>        (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
>        are saying  want  to  do  this,  we  need  a  more  specific
>        proposal.

If that more specific proposal allows recurrences like "second tuesday in=20
September"...
=46or the more involved example of the US presidential election day, I don'=
t=20
think the issue is how to represent this in a GUI. I doubt that such a rule=
=20
would be entered by an ordinary user. But for centralized calendar=20
repositories, where people can subscribe to calendars, iCalendar (or howeve=
r=20
it will be called) needs to be able to express such a complex recurrence,=20
too.

>        (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
>        that allows this.  Deprecate it?

This is needed to allow, for example last work day of the month/year.=20
Evolution currently supports this, so does Connect Daily, and I'm planning =
on=20
adding it to korganizer.

>        (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
>        this is a compatibility issue as a CUA can or can not use it
>        and it does not effect the data or flow of data.  Thin CUA's
>        can not use it anyway and ignore it.  Having  this  property
>        does  not break CUAs that do not use it.  How many use this?

KOrganizer, for example, lets you attach URIs to your events and todo items=
=2E=20
They are shown in the event viewer / reminder dialog as links.=20
KOrganizer also lets you attach a link to a mail message in kmail (by simpl=
y=20
dragging the mail to the todo).

>        (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.

Yes. Related-to is the current way to implement hierarchical todo-lists, li=
ke=20
KOrganizer does.

Just my 2 cents on this topic...

Cheers,
Reinhold

=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.a=
t/
 * KOrganizer / KPilot maintainer, K Desktop Environment, http://www.kde.or=
g/

--nextPart1242059.rRcZgWYXgS
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBSx/9TqjEwhXvPN0RAsg+AKDGI0TCIaFMhgJWiK6IMEcwR2+kzQCePxkQ
Vt8iSTozy65p+fV8B0xvxV8=
=Foey
-----END PGP SIGNATURE-----

--nextPart1242059.rRcZgWYXgS--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8HE35po031711 for <[e-mail]>; Fri, 17 Sep 2004 07:03:05 -0700
Received: from [192.168.1.100] [66.82.50.1] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id A83F4F6E010C; Fri, 17 Sep 2004 06:35:59 -0700
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Nathaniel Borenstein <[e-mail]>
Subject: Re: [Ietf-calsify] ISO Standard relevant to timezone and time representation discussions
Date: Fri, 17 Sep 2004 10:02:23 -0400
To: [e-mail]
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Sep 2004 14:03:08 -0000

FYI, I'm the "at least one person" Dave refers to, and I found this (as  
I've told some of you) eye-opening.  I'm not sure that it will have any  
direct consequences for us, but I found it useful to look at a rather  
different perspective on the same problems we're focused on here.   
Anyway at $18, it's a cheap exercise in broadening one's perspective.   
-- Nathaniel

On Sep 16, 2004, at 10:26 PM, David C. Thewlis wrote:

> There's an ISO standard which I think is very relevant to the work  
> being
> done by the people on these discussion lists, in particular in  
> discussions
> of representation and management of time values.  The standard in  
> question
> is:
>
> ISO 19108 (2002), Geographic Information:  Temporal Schema
> developed by ISO/TC211, Geograhic Information/Geomatics
>
> The scope of this standard is described as:
>
> "This International Standard defines concepts for describing temporal
> characteristics of geographic information. It depends upon existing
> information technology standards for the interchange of temporal
> information. It provides a basis for defining temporal feature  
> attributes,
> feature operations, and feature associations, and for defining the  
> temporal
> aspects of metadata about geographic information. Since this standard  
> is
> concerned with the temporal characteristics of geographic information  
> as
> they are abstracted from the real world, it emphasises valid time  
> rather
> than transaction time."
>
> I know at least one person on this discussion list has looked at this
> standard and there may be others, if anyone else would care to comment  
> on
> its relevance.
>
> I'll put info below on how to get a copy.
>
> Dave Thewlis, Executive Director
> The Calendaring and Scheduling Consortium
> [phone] (voice)
> [phone] (fax)
> [phone] (mobile)
> [e-mail]
> www.calconnect.org
>
> ----------------------------------------------------------------------- 
> -----
> ---------------
>
> How to get a copy of ISO 19108
>
> You can purchse a copy of this standard for $18 by downloading it from  
> the
> ANSI webstore (you can also get a copy directly from ISO but it costs  
> 140
> Swiss Francs that way).
>
> Point your browser to:   
> http://webstore.ansi.org/ansidocstore/default.asp
>
> Enter "19108" in the top left "search" box and click go
>
> You'll be offered two choices:  "ISO 19108:2002" for $113.00" and
> "INCITS/ISO 19108:2002" for $18.  They are the same document; INCITS  
> (the
> U.S. national IT standards committee) has registered the international
> standard as a parallel national standard and can thus sell it at its  
> own
> charge, which it has set very low.
>
> The site will talk you through the process of purchasing a copy on a  
> credit
> card and downloading it.  Note that you have to agree on the copyright  
> and
> license agreement; the bottom line is you can't copy and distribute it  
> or
> make it available on a network (they want to you get a separate copy  
> for
> each person who will use it).
>
> But at $18 I'm not sure that is a serious impediment.
>
> Dave Thewlis
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from hal-5.inet.it (hal-5.inet.it [213.92.5.24]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8H74Xpo008541 for <[e-mail]>; Fri, 17 Sep 2004 00:04:33 -0700
Received: from hhazewinkel.inet.it [::ffff:213.92.1.191] by hal-5.inet.it via I-SMTP-5.1.13-51A id ::ffff:213.92.1.191+btq4OCp8cnJq; Fri, 17 Sep 2004 09:04:27 +0200
Message-ID: <[e-mail]>
Date: Fri, 17 Sep 2004 09:04:26 +0200
From: Harrie Hazewinkel <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] UTC
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Sep 2004 07:04:35 -0000

[e-mail] wrote:
> To me, saying UTC minus 5 hours pretty specifically specifies the time 
> adjustment - different timezone names might map to the same offset, but 
> it's the offset that matters.  The name is merely a way to find the 
> offset when you need to do the calculation. That said, I still think it 
> is simpler to use UTC for storing and exchanging everything; though some 
> property of where the event actual takes place is needed to map that 
> into local time.

While I beleive it may be useful to have the name as the offset
(as mentioned different daylight savings rules), this technology is used 
more and more in small devices like phones and those do (at this moment)
not have huge space to store the 'named' offset. On top of that 
calculating time with the numeric offset is more simple and I believe
more supported.
Therefore, I beleive exchanging UTC is better and one could use the
LOCATION property to map it if a device is able to do that.

Harrie
> 
> At 10:22 AM 9/16/04, Cyrus Daboo wrote:
> 
>> Hi [e-mail],
>>
>> --On Thursday, September 16, 2004 12:10 AM -0400 [e-mail] 
>> wrote:
>>
>>> Adding TZID to an event with a UTC time code, however,  is just the
>>> converse of using the ISO 8601 date/time format _with_ the timezone
>>> designator. 2004-09-15T23:59:00-0500  is basically the same as saying
>>> 20040916T045900Z;TZID=EST isn't it?
>>
>>
>> -0500 can map to several different timezones with different daylight 
>> savings rules, so it is not enough to just specify the numeric offset 
>> if the event is recurring and might span a dst change or there is any 
>> likelyhood the event could be moved across a dst change.
>>
>> -- 
>> Cyrus Daboo
> 
> 
> Tim Hare
> Interested Bystander, Non-Inc.
> 
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from custmail0.corp.aus.wayport.net (custmail0.corp.aus.wayport.net [216.12.231.21]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8H2RHpp004423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 16 Sep 2004 19:27:18 -0700
Received: from davet23 (dhcp64-134-26-93.wwd.chi.wayport.net [64.134.26.93]) by custmail0.corp.aus.wayport.net (8.12.10/8.12.10) with ESMTP id i8H2QtRq019296 for <[e-mail]>; Fri, 17 Sep 2004 02:27:17 GMT
Message-ID: <[e-mail]>
X-Mailer: Calypso Version 3.30.00.00 (4)
Date: Thu, 16 Sep 2004 19:26:20 -0700
From: "David C. Thewlis" <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] ISO Standard relevant to timezone and time representation discussions
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Sep 2004 02:27:19 -0000

There's an ISO standard which I think is very relevant to the work being
done by the people on these discussion lists, in particular in discussions
of representation and management of time values.  The standard in question
is:

ISO 19108 (2002), Geographic Information:  Temporal Schema
developed by ISO/TC211, Geograhic Information/Geomatics

The scope of this standard is described as:

"This International Standard defines concepts for describing temporal
characteristics of geographic information. It depends upon existing
information technology standards for the interchange of temporal
information. It provides a basis for defining temporal feature attributes,
feature operations, and feature associations, and for defining the temporal
aspects of metadata about geographic information. Since this standard is
concerned with the temporal characteristics of geographic information as
they are abstracted from the real world, it emphasises valid time rather
than transaction time."

I know at least one person on this discussion list has looked at this
standard and there may be others, if anyone else would care to comment on
its relevance.

I'll put info below on how to get a copy.

Dave Thewlis, Executive Director 
The Calendaring and Scheduling Consortium
[phone] (voice)
[phone] (fax)
[phone] (mobile)
[e-mail]
www.calconnect.org

----------------------------------------------------------------------------
---------------

How to get a copy of ISO 19108

You can purchse a copy of this standard for $18 by downloading it from the
ANSI webstore (you can also get a copy directly from ISO but it costs 140
Swiss Francs that way).

Point your browser to:  http://webstore.ansi.org/ansidocstore/default.asp

Enter "19108" in the top left "search" box and click go

You'll be offered two choices:  "ISO 19108:2002" for $113.00" and
"INCITS/ISO 19108:2002" for $18.  They are the same document; INCITS (the
U.S. national IT standards committee) has registered the international
standard as a parallel national standard and can thus sell it at its own
charge, which it has set very low.

The site will talk you through the process of purchasing a copy on a credit
card and downloading it.  Note that you have to agree on the copyright and
license agreement; the bottom line is you can't copy and distribute it or
make it available on a network (they want to you get a separate copy for
each person who will use it).  

But at $18 I'm not sure that is a serious impediment.

Dave Thewlis



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8H26Dpo003021 for <[e-mail]>; Thu, 16 Sep 2004 19:06:13 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc11) with SMTP id <2004091702060701100ik8kte> (Authid: TimHare); Fri, 17 Sep 2004 02:06:07 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Thu, 16 Sep 2004 22:05:17 -0400
To: Cyrus Daboo <[e-mail]>, [e-mail]
From: [e-mail]
Subject: Re: [Ietf-calsify] UTC
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.39
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Sep 2004 02:06:14 -0000

To me, saying UTC minus 5 hours pretty specifically specifies the time 
adjustment - different timezone names might map to the same offset, but 
it's the offset that matters.  The name is merely a way to find the offset 
when you need to do the calculation. That said, I still think it is simpler 
to use UTC for storing and exchanging everything; though some property of 
where the event actual takes place is needed to map that into local time.

At 10:22 AM 9/16/04, Cyrus Daboo wrote:
>Hi [e-mail],
>
>--On Thursday, September 16, 2004 12:10 AM -0400 [e-mail] wrote:
>
>>Adding TZID to an event with a UTC time code, however,  is just the
>>converse of using the ISO 8601 date/time format _with_ the timezone
>>designator. 2004-09-15T23:59:00-0500  is basically the same as saying
>>20040916T045900Z;TZID=EST isn't it?
>
>-0500 can map to several different timezones with different daylight 
>savings rules, so it is not enough to just specify the numeric offset if 
>the event is recurring and might span a dst change or there is any 
>likelyhood the event could be moved across a dst change.
>
>--
>Cyrus Daboo

Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8GEMCpp005187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 16 Sep 2004 07:22:13 -0700
Received: from [10.0.1.3] (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i8GE1go3007641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Sep 2004 10:01:43 -0400
Date: Thu, 16 Sep 2004 10:22:09 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: [Ietf-calsify] UTC
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Scanned-By: MIMEDefang 2.39
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Sep 2004 14:22:13 -0000

Hi [e-mail],

--On Thursday, September 16, 2004 12:10 AM -0400 [e-mail] wrote:

> Adding TZID to an event with a UTC time code, however,  is just the
> converse of using the ISO 8601 date/time format _with_ the timezone
> designator. 2004-09-15T23:59:00-0500  is basically the same as saying
> 20040916T045900Z;TZID=EST isn't it?

-0500 can map to several different timezones with different daylight 
savings rules, so it is not enough to just specify the numeric offset if 
the event is recurring and might span a dst change or there is any 
likelyhood the event could be moved across a dst change.

-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8G9GKpo020618 for <[e-mail]>; Thu, 16 Sep 2004 02:16:20 -0700
Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by dirg.bris.ac.uk with esmtp (Exim 4.34) id 1C7sNB-00019c-Js for [e-mail]; Thu, 16 Sep 2004 10:16:14 +0100
Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 4.34) id 1C7sNA-0000C3-7o for [e-mail]; Thu, 16 Sep 2004 10:16:13 +0100
Date: Thu, 16 Sep 2004 10:16:12 +0100 (BST)
From: Libby Miller <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: [Ietf-calsify] List issues so far.
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: Libby Miller <[e-mail]>
X-Spam-Level: /
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Sep 2004 09:16:21 -0000

hi Doug

Well, anything you feel happy sharing would be most welcome.

Libby

On Wed, 15 Sep 2004, Doug Royer wrote:

>
>
> Libby Miller wrote:
>
>> 
>> 
>> On Tue, 14 Sep 2004, Doug Royer wrote:
>> 
>>> I have seached thousands of VCALENDAR objects on the net and I have
>>> tested over 40 calendar products or net accounts for calendars or PDAs, 
>>> and never
>>> found anything other than an RFC example of its usage.
>>> 
>> 
>> Doug, is there any chance you could make this (raw) data available to us? 
>> It would be really helpful.
>> 
>> all the best 
>
>
> I can post a url to many of the .ICS files that I have found on the net 
> However many are uploaded
> at test time from sites and I do not have copies of them.  I used a tweaked 
> 'wget' to snag
> many and feed it into a program that counted the component, property, and 
> parameter
> types used and some values of specific properties. So in many cases I have 
> the results
> and not the raw data.
>
> -- 
>
> Doug Royer                     |   http://INET-Consulting.com
> -------------------------------|-----------------------------
> [e-mail]                 | Office: [phone]
> http://Royer.com/People/Doug   | Fax:    [phone]
>                              | Cell:   [phone]
>
>             We Do Standards - You Need Standards
>
>
>


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8G4Bipo002742 for <[e-mail]>; Wed, 15 Sep 2004 21:11:44 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc12) with SMTP id <20040916041138012007fsg9e> (Authid: TimHare); Thu, 16 Sep 2004 04:11:38 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Thu, 16 Sep 2004 00:10:40 -0400
To: [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] UTC
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Sep 2004 04:11:45 -0000

Most of the "travelling" scenarios that have been posted as arguments 
against UTC storage, seem to me to be workable with the date/time stored in 
UTC but the timezone of the event noted as a property, as someone 
suggested, allowing a client to look up the timezone and do the calculation 
if necessary.

Adding TZID to an event with a UTC time code, however,  is just the 
converse of using the ISO 8601 date/time format _with_ the timezone 
designator. 2004-09-15T23:59:00-0500  is basically the same as saying 
20040916T045900Z;TZID=EST isn't it?  RFC2445 section 4.3.5 specifically 
says not to use this format, although I don't know the reasoning behind 
that.  In any event, rather than having the client retain a lookup table to 
convert EST to "subtract five hours from Zulu", why don't we just send the 
offset value along with the date/time value. This has the added advantage 
of allowing implementors to borrow code from already working e-mail 
implementations, since it is the format used in mail headers. I'm sure 
there are disadvantages I've overlooked, but it does seem like an option 
(to me).

And for the record or consensus vote, I'm more comfortable with everything 
in UTC. I believe the clients can deal with it. Possibly they already do - 
most communicating clients using cell phone technology might record 
messages in local time, but if the billing folks aren't in the same time 
zone, some conversion must take place to log the call for billing purposes, 
I would think?


Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8FHvvpp005929 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Wed, 15 Sep 2004 10:57:59 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8FHvkmq026496 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 15 Sep 2004 10:57:48 -0700
Message-ID: <[e-mail]>
Date: Wed, 15 Sep 2004 11:57:46 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] List issues so far.
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040207070307000207090709"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Sep 2004 17:58:00 -0000

This is a cryptographically signed message in MIME format.

--------------ms040207070307000207090709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Libby Miller wrote:

>
>
> On Tue, 14 Sep 2004, Doug Royer wrote:
>
>> I have seached thousands of VCALENDAR objects on the net and I have
>> tested over 40 calendar products or net accounts for calendars or 
>> PDAs, and never
>> found anything other than an RFC example of its usage.
>>
>
> Doug, is there any chance you could make this (raw) data available to 
> us? It would be really helpful.
>
> all the best 


I can post a url to many of the .ICS files that I have found on the net 
However many are uploaded
at test time from sites and I do not have copies of them.  I used a 
tweaked 'wget' to snag
many and feed it into a program that counted the component, property, 
and parameter
types used and some values of specific properties. So in many cases I 
have the results
and not the raw data.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms040207070307000207090709
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTE1MTc1NzQ2WjAjBgkqhkiG9w0BCQQxFgQUnAnrd7/Bjlx7fTJN/+V2
/SFlo6EwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAmR20l8IpPBKOOjDvCL8rHN6aFPJ12j/aZ8A5Yg0QWe8SNJcEjqO/LrSsFKmZjQ8F
cHY0KbI6Zp/CUMpGEf2IKDnuBnezdPn76S3m3WLJdqQtVOcrHKZOM4T4fMp2saBlWFOrox8f
zIVfbYXfO4MBgU7VABjM2OxCrHaveaI1JkQTRlmDHVAxl9rkRX1mDSP8PTS0Fvx6kH85747f
kTRaftsPjzVTp4iD3jOuFu0gRqc+8DhCVhnIhys9Zw3Q3fNbTjQUStLxCB+XyQWomh2lZvbl
Tt+5JtvpvQ58E6SI44QiYvaaJs+1dNRFCwq5HUNgyxRLQPlwcRlp0CRrVq+MzgAAAAAAAA==
--------------ms040207070307000207090709--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8FCn3po017267 for <[e-mail]>; Wed, 15 Sep 2004 05:49:03 -0700
Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id AC1224F121; Wed, 15 Sep 2004 08:49:02 -0400 (EDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <1094855069.6086.489.camel@dirk> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Dan Connolly <[e-mail]>
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
Date: Wed, 15 Sep 2004 13:49:01 +0100
To: Leo Sauermann <[e-mail]>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.39
X-Mailman-Approved-At: Wed, 15 Sep 2004 08:44:20 -0700
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Sep 2004 12:49:04 -0000

On Sep 14, 2004, at 3:41 PM, Leo Sauermann wrote:

>
>
>>
>> Also in the debate on this list was listing all entries in UTC.  This
>> would eliminate the need for VTIMEZONE in many (all?) components.
>> Yet the CUA still needs to do TZ math.  So this is a proposal on
>> how to have simple IANA registered time zones so that everyone does
>> the same math.
>
> uhhh..
> many of todays calendars in VCAL have errors about timezones.
> If mozilla/kde/whatever doesn't get it, we rdf developers won't get 
> it, too.

But mozilla/kde/whatever do get it, increasingly.

Don't let's fall into the trap of thinking that producing new 
specifications
will fix the fact that the old ones aren't implemented well.

> so I would recommend to always store time in local time format with 
> timezone, because any UI (cell phone, whatever) then may display it 
> without any math.

But if it can't tell that a meeting at 1pm NY time conflicts with a 
meeting at 12noon Chicago time, what good is that? Just use plain text 
if you don't want the computer to actually help.

-- 
Dan



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8FCW7po014633 for <[e-mail]>; Wed, 15 Sep 2004 05:32:07 -0700
Received: by homer.w3.org (Postfix, from userid 13795) id 45B124F0CC; Wed, 15 Sep 2004 08:32:07 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id 443914F060; Wed, 15 Sep 2004 08:32:07 -0400 (EDT)
Date: Wed, 15 Sep 2004 08:32:07 -0400 (EDT)
From: Charles McCathieNevile <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <1094855069.6086.489.camel@dirk> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Sep 2004 12:32:08 -0000

On Tue, 14 Sep 2004, Elias Sinderson wrote:

>Charles McCathieNevile wrote:
>
>>On Tue, 14 Sep 2004, Leo Sauermann wrote:
>>
>>>[...] I would recommend to always store time in local time format with timezone, because any UI (cell phone, whatever) then may display it without any math.
>>>
>>[...] I don't think in real-world applications you can get away with not being able to do the maths.
>>
>+1
>
>>I have a cellphone and a laptop, and sync my calendars between them. I have
>>several problems:
>>
>>Some events have a different timezone for the start and end (most often,
>>aeroplane flights - the data I get gives the departure and arrival times as
>>local to the relevant airport.
>>
>Would it be acceptable for the client to display all the times in local
>time, whatever that may be? For example, in New York you would see the
>times for the flight displayed in New York time, and when  in Paris you
>would see the times as local to Paris. Personally I could live with
>this, especially if my client allowed me to dynamically switch the
>display timezone.

That's what I have at the moment. If I find a calendar program that does
better, I'll ditch the current one. The problem is as follows:

I am in Antibes, and I have a flight that goes from Frankfurt (same time zone
as Antibes in this case) to Shanghai (some other time), where I meet my
mother. She wants to know when I get to the airport. I'd like to have the
time blocked off for making appointments according to Antibes time (and so I
can see how many hours I will spend in the plane, but I want to be able to
quickly look up my arrival time in the most useful form, which is generally
going to be Shanghai time. (Not always, but IMHO there should be nothing to
stop me noting an event in UTC or something if I want to).

>>[...] recurrent events have their time specified in different time zones. For
>>instance I have one recurrent meeting with times expressed in France/Paris
>>time, and another expressed in US/Boston time.
>>
>It would seem that keeping all of these times in UTC would avoid you
>having to switch the timezone settings on your client.

Not really, unless you are prepared to switch each instance of a recurrent
event, checking when the changes to summer time are. In fact it is important
on some timezones to know what the original timezone was, since you can't
always predict in advance when timezones shift. (In 2000, the state of New
South Wales announced that it would introduce summer time many weeks earlier
than usual to allow for better TV programming times for the Olympics. I don't
want to have to then tell my calendar to recalculate everything that was
noted in sydney time originally by hand - if I have to tell it that Sydney is
already on summer time (I believe that I still have to do that currently)
that's more than enough hassle.

>>[...]
>If we agree that the canonical server representation MUST be in UTC,

I don't - I think the idea of keeping the thing in a local time and noting
its timezone is a good one. I just don't think that it achieves the goal of
avoiding the maths. On the other hand it achieves the goal of maintaining an
important data point so we can get the right result if we do the maths right,
in a way that seems (to me) likely to be less troubling in the long run than
always
relying on UTC.

cheers

Chaals


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8F82Apo026070 for <[e-mail]>; Wed, 15 Sep 2004 01:02:11 -0700
Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by dirg.bris.ac.uk with esmtp (Exim 4.34) id 1C7Ujr-0001pp-PV for [e-mail]; Wed, 15 Sep 2004 09:02:05 +0100
Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 4.34) id 1C7Ujq-0001Gr-5p for [e-mail]; Wed, 15 Sep 2004 09:02:02 +0100
Date: Wed, 15 Sep 2004 09:02:02 +0100 (BST)
From: Libby Miller <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: [Ietf-calsify] List issues so far.
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: Libby Miller <[e-mail]>
X-Spam-Level: /
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Sep 2004 08:02:11 -0000

On Tue, 14 Sep 2004, Doug Royer wrote:
> I have seached thousands of VCALENDAR objects on the net and I have
> tested over 40 calendar products or net accounts for calendars or PDAs, and 
> never
> found anything other than an RFC example of its usage.
>

Doug, is there any chance you could make this (raw) data available to 
us? It would be really helpful.

all the best

Libby


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EMI1po025471 for <[e-mail]>; Tue, 14 Sep 2004 15:18:01 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 1305C284D5E; Wed, 15 Sep 2004 00:17:28 +0200 (CEST)
Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 93E85284D3B; Wed, 15 Sep 2004 00:17:25 +0200 (CEST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <1094855069.6086.489.camel@dirk>	<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
Date: Wed, 15 Sep 2004 00:17:52 +0200
To: [e-mail]
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 22:18:03 -0000

On Sep 14, 2004, at 23:57, Cyrus Daboo wrote:
> Displaying them in your local 'display' timezone is fine, but what 
> about editing them? If I enter a date-time with a specific timezone 
> and then go back to edit that, I want to see it in the timezone I 
> originally entered, not whatever my current 'display' timezone is.

-1.
I don't know in what situation that would be important. Sounds more 
like a free form history log for informational purposes (like "created 
as event 'blub' in Seattle, PST").

> If we do switch to using only UTC times I would like to suggest that 
> we preserve the original timezone info using a 'TZHINT' attribute on 
> the date-time property.

+1
Sounds good! An optional attribute which transports that information.

> That way clients would know what timezone to use when the user wants 
> to edit.

This is relevant for calculated cycles, in all other cases the user 
will probably expect the current view timezone to be used for edits as 
well (not to be discussed, opinions might differ ;-).

>  The question is whether that is really any different than what we 
> have now...

Yes it is! The storage/transport would be allowed to ignore the hint 
(which will be quite usual if you consider the amount of requests for 
UTC!), but systems supporting the hint could still provide the 
information.
Which is why I like the solution.

The "issue" to be solved are calculated cyclic appointments. I would 
personally vote to remove them, but I know that a lot of 
devices/clients already depend on it (eg Palm PDAs and Outlook). I see 
three levels of recurrence support:

a) no recurrences in the protocol (client must flatten cycles to 
individual events),
    implies that timezone info is not necessary anymore (hurray!)
b) recurrences allowed on creation, kept in storage (servers will 
return individual
    events on queries). Only needs timezone for recurrences on creation.
c) recurrences fully supported (current situation). Client and server 
need to be fully
    timezone aware and have consistent information on that.

Reducing to a) would certainly make the protocol/format a _whole_ lot 
easier. b) still gives a big boost in interoperability and is easier. 
But c) is actually required for a lot of systems.

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EMDJpp025154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Sep 2004 15:13:20 -0700
Received: from plato.cyrusoft.com (plato.cyrusoft.com [63.163.82.23]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i8ELr6o3016228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Sep 2004 17:53:07 -0400
Date: Tue, 14 Sep 2004 18:16:35 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] List issues so far.
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 22:13:20 -0000

Hi Doug,

--On Tuesday, September 14, 2004 1:57 PM -0600 Doug Royer <[e-mail]> 
wrote:

>> You need BYSETPOS to say "the first/last weekday of the month", which I
>> think is supported by more than one CUA.
>>
>>
> I have seached thousands of VCALENDAR objects on the net and I have
> tested over 40 calendar products or net accounts for calendars or PDAs,
> and never
> found anything other than an RFC example of its usage.
>
> If it is in use - great!

My client allows users to have a 'first' or 'last' bysetpos. Not that many 
people are using it right now, but I do have one event on my calendar that 
uses BYSETPOS - namely 'PAY DAY' - the last week day in the month!

RRULE:FREQ=MONTHLY;BYDAY=-1MO,-1TU,-1WE,-1TH,-1FR;BYSETPOS=-1


-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8ELsOpp023480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Sep 2004 14:54:24 -0700
Received: from plato.cyrusoft.com (plato.cyrusoft.com [63.163.82.23]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i8ELYBo3015732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Sep 2004 17:34:11 -0400
Date: Tue, 14 Sep 2004 17:57:40 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <1094855069.6086.489.camel@dirk>	<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 21:54:25 -0000

Hi Elias,

--On Tuesday, September 14, 2004 1:00 PM -0700 Elias Sinderson 
<[e-mail]> wrote:

>> Some events have a different timezone for the start and end (most often,
>> aeroplane flights - the data I get gives the departure and arrival times
>> as local to the relevant airport.
>>
> Would it be acceptable for the client to display all the times in local
> time, whatever that may be? For example, in New York you would see the
> times for the flight displayed in New York time, and when  in Paris you
> would see the times as local to Paris. Personally I could live with this,
> especially if my client allowed me to dynamically switch the display
> timezone.

Displaying them in your local 'display' timezone is fine, but what about 
editing them? If I enter a date-time with a specific timezone and then go 
back to edit that, I want to see it in the timezone I originally entered, 
not whatever my current 'display' timezone is.

If we do switch to using only UTC times I would like to suggest that we 
preserve the original timezone info using a 'TZHINT' attribute on the 
date-time property. That way clients would know what timezone to use when 
the user wants to edit. The question is whether that is really any 
different than what we have now...

-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from custmail0.corp.aus.wayport.net (custmail0.corp.aus.wayport.net [216.12.231.21]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EL5App017411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Sep 2004 14:05:11 -0700
Received: from davet23 (dhcp64-134-26-103.wwd.chi.wayport.net [64.134.26.103]) by custmail0.corp.aus.wayport.net (8.12.10/8.12.10) with ESMTP id i8EL4vRq022082 for <[e-mail]>; Tue, 14 Sep 2004 21:05:05 GMT
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Calypso Version 3.30.00.00 (4)
Date: Tue, 14 Sep 2004 14:00:26 -0700
From: "David C. Thewlis" <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] Re: Testing and Interops
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 21:05:12 -0000

Pat Egen posted to this list that she was waiting for the last of the
results from the testers before completing her detailed report on the
Interop at UCB.  The final results were sent to her late last week, but Pat
had just left on vacation trip.  I believe she returns around the 25th, so
we can hope for her final report shortly after that.  

Our apologies for the delay, but as Pat said she wanted to make the report
as complete as possible and clearly the results from all of the testers
were important.

Dave Thewlis
Executive Director
The Calendaring and Scheduling Consortium





X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from custmail0.corp.aus.wayport.net (custmail0.corp.aus.wayport.net [216.12.231.21]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EKrppp015213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Sep 2004 13:53:52 -0700
Received: from davet23 (dhcp64-134-26-103.wwd.chi.wayport.net [64.134.26.103]) by custmail0.corp.aus.wayport.net (8.12.10/8.12.10) with ESMTP id i8EKrbRq017460 for <[e-mail]>; Tue, 14 Sep 2004 20:53:46 GMT
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Calypso Version 3.30.00.00 (4)
Date: Tue, 14 Sep 2004 13:49:06 -0700
From: "David C. Thewlis" <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] Testing and interops
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 20:53:53 -0000

On 9/14/2004 at 14:32 Doug Royer wrote:

>And the 2nd point is that if we do not know what the vendors are doing
>then how can we declare anything interoperable? We only have a small
>number of vendors that could afford the commercial testing.

I presume by "commercial testing" you are referring to the Calconnect
Interops that The Calendaring and Scheduling Consortium was in part created
to conduct?  FYI we set the fee at $1500 for members and $2500 for
nonmembers, which is intended to be a revenue-neutral fee at the size we
expect an Interop to be.  Granted that's not *cheap* but it's not horribly
expensive either.

We have talked about doing virtual interops in the future (although I
gather the consensus from the last virtual interop was that overall the
in-person sessions are more productive), but don't have any current plans
for one.  

We'll be happy to start planning for the next one either virtual or real,
as soon as there's a need for one.  It hasn't been clear to me that we
would need further Interops on the current RFCs as opposed to what may come
of these discussions, but there's absolutely no reason we go ahead with one
now folks see a need.

Dave thewlis
Executive Director
The Calendaring and Scheduling Consortium



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EKWmpp007883 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Tue, 14 Sep 2004 13:32:49 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8EKWcSw008256 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 14 Sep 2004 13:32:41 -0700
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 2004 14:32:38 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030101050107070606060306"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] Re: charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 20:32:50 -0000

This is a cryptographically signed message in MIME format.

--------------ms030101050107070606060306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>> Fortunately this mailing list is not "how can it be done", its "how 
>> do people do it".
>
>
> This shows again why we need a clear charter -- for my part, I don't 
> think *either* of those characterize our goal very well, but I'm 
> closer to the former than the latter.


It was my understanding that the goal was interoperability. For that I read
(in the simple case) if a HUGE number of venders do SOMETHING
and SOMETHING is working. it would seem to me to be easier
to make the smaller number of vendors change to the SOMETHING method.
Of course things are never that simple.

And the 2nd point is that if we do not know what the vendors are doing
then how can we declare anything interoperable? We only have a small
number of vendors that could afford the commercial testing.

Which is why it seems to me to be "how do people do it".

There seems to be 3 basic types of iCAL usage:

  (1) iMIP

  (2) The HTTP/WEBDAV POST/GET of objects - or WEB calendars
         that import/export iCAL.

  (3) PDA's and synchronization (And the 3 CAP vendors).

What vendors put in each has some overlap.

VALARMS go into (2) and (3) and almost never in (1)

Several common custom properties go into (2) and (3) and a different
set of common custom properties tend to go into (1).

I think we need to figure out the MINIMUM set that works for everyone
(as in how they do it now) and that needs to go into the 'basic' ical draft.
And I think we need to recognize that some large vendors did not do
it as documented. And have failed to document how they do it. These
need to be weeded out as noise as no one can be compatible with
undocumented procedures.

Same with scheduling. We need to figure out the basic minimum for
scheduling and that needs to be in 'basic-scheduling draft'.

Everything else I think need to be in add-on drafts.

If this is an iCAL-next, I think we are opening up the scope to years
of debate - which is how I read "how can it be done".

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms030101050107070606060306
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTE0MjAzMjM4WjAjBgkqhkiG9w0BCQQxFgQUyAnfruc69RrPmQ4S8oSt
VGCfQmEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAuWhUpOK8lntj032G0UVy3eWRrcDAFAvhmKMydj6ktRmba141iEXiMuWGcIylkNJH
E9BSszwOtaqOFT82B0M4tsi6uB5jmV7cyqjr4kCTY3sdHrvMCZswfi6q2jkfWvhw86akGo7P
5fTAdmWBQLzZ+PU1aA/5Wp+mv38UYih8/IyJHkLs+wP/fsTs4xsx1uPRX7W/MWi4I+wkT/x2
cjCsemhzESt5ARWKwxoZ5X0DO9D9Lf+4MNFjUmScIMBmS3/D+q0YEA9j5PyKJQbku/F7gZwN
ZyOo2lynnEGgBHqSvHpIZE0ursIurm1aI4WMH2aKeIWidvF6VdcZtyvXnlEFbgAAAAAAAA==
--------------ms030101050107070606060306--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EK08po000406 for <[e-mail]>; Tue, 14 Sep 2004 13:00:08 -0700
Received: from cse.ucsc.edu (adsl-63-194-88-161.dsl.snfc21.pacbell.net [63.194.88.161]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id i8EK0DhY014473; Tue, 14 Sep 2004 16:00:13 -0400
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 2004 13:00:20 -0700
From: Elias Sinderson <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
References: <[e-mail]>	<1094855069.6086.489.camel@dirk> <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 20:00:09 -0000

Charles McCathieNevile wrote:

>On Tue, 14 Sep 2004, Leo Sauermann wrote:
>
>  
>
>>[...] I would recommend to always store time in local time format with timezone, because any UI (cell phone, whatever) then may display it without any math.
>>    
>>
>[...] I don't think in real-world applications you can get away with not being able to do the maths.
>  
>
+1

>I have a cellphone and a laptop, and sync my calendars between them. I have
>several problems:
>
>Some events have a different timezone for the start and end (most often,
>aeroplane flights - the data I get gives the departure and arrival times as
>local to the relevant airport.
>
Would it be acceptable for the client to display all the times in local 
time, whatever that may be? For example, in New York you would see the 
times for the flight displayed in New York time, and when  in Paris you 
would see the times as local to Paris. Personally I could live with 
this, especially if my client allowed me to dynamically switch the 
display timezone.

>[...] recurrent events have their time specified in different time zones. For
>instance I have one recurrent meeting with times expressed in France/Paris
>time, and another expressed in US/Boston time.
>
It would seem that keeping all of these times in UTC would avoid you 
having to switch the timezone settings on your client.

>[...] One-off Web events and the like are often specified in a local time based on
>where the guy writing the page is. This seems reasonable. But if I have
>to shift my software around to that timezone to enter the time, it's a pain,
>and any given person is unlikely to specify things in lots of timezones.
>  
>
If we agree that the canonical server representation MUST be in UTC, I 
propose adding the following text to the spec as well. "Clients SHOULD 
allow a user to specify times for events in any timezone." At any rate, 
changing the timezone setting on your client in order to enter an event 
seems warped. (No offense intended, clearly the calendar client you are 
using is forcing you to work around it's shortcomings.)

>I tried keeping one clock synched to UTC and doing everything based on that.
>As someone who changes timezones on average more than once a week I thought
>it would make sense, but it doesn't.
>
I've lived in multiple timezones simultaneously as well, keeping watches 
sync'd to different timezones. The real problems occurred when I was so 
tired that I put them on the wrong wrist...

>The maths is a bit more complex than straight addition/subtraction, but not very. Most of the complexity is to do with looking up tables. That sounds to me like the kind of maths that we
>should rely on computers to do [...]
>
+1


Regards,
Elias


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EJx4po000353 for <[e-mail]>; Tue, 14 Sep 2004 12:59:04 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 53E8F284C2E; Tue, 14 Sep 2004 21:58:39 +0200 (CEST)
Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id AB9F5284BF5; Tue, 14 Sep 2004 21:58:38 +0200 (CEST)
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<1094855069.6086.489.camel@dirk> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
Date: Tue, 14 Sep 2004 21:58:56 +0200
To: [e-mail]
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 19:59:06 -0000

On Sep 14, 2004, at 21:44, Elias Sinderson wrote:
> The math consists of a single lookup and a single addition or 
> subtraction, or the equivalent of a switch statement based on the 
> current client timezone... Even cell phones can do that without 
> difficulty, as can handhelds, etc.

The calculation itself isn't too difficult. But storing (and updating) 
the timezone information for all the years might be a storage problem 
for cell phones? (though cell phones nowadays have enough RAM, but your 
new cell phone watch might not ;-).

> Quite honestly, storing all times in UTC is the simplest solution. It 
> is well within the extent of client capabilities to translate times 
> from UTC to the local client setting.

Except that it doesn't work for (calculated) cyclic appointments which 
need to take into account daylight savings which in turn requires the 
timezone information.
Do I miss something? (I have the impression, because this was suggested 
several times now).

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (royer.com [4.23.9.161]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EJvgpp032728 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Tue, 14 Sep 2004 12:57:43 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8EJvXSw007540 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 14 Sep 2004 12:57:35 -0700
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 2004 13:57:32 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] List issues so far.
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020809080001000205000006"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 19:57:45 -0000

This is a cryptographically signed message in MIME format.

--------------ms020809080001000205000006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Dan Winship wrote:

>On Mon, 2004-09-13 at 17:18 -0600, Doug Royer wrote:
>  
>
>>       (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
>>       that allows this.  Deprecate it?
>>    
>>
>
>You need BYSETPOS to say "the first/last weekday of the month", which I
>think is supported by more than one CUA.
>  
>
I have seached thousands of VCALENDAR objects on the net and I have
tested over 40 calendar products or net accounts for calendars or PDAs, 
and never
found anything other than an RFC example of its usage.

If it is in use - great!

Maybe we need to start collecting:

    (A) A CUA feature list (released products only).
    (B)  An object contents list.

Then perhaps only then we can start throwing out the unused or knowing
what is incompatible.

>>       (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
>>       want  to  do this
>>    
>>
>
>Really?
>
It did look to me as if the list was leaning to yes. Which is why I 
raised the point.

I for one think that we need to standardize on TZ's contents (hence my 
draft).
Standardized TZ's I think are needed ether way.

I also feel that everything in Z would be too much of a change. It just 
looked
to me as if people wanted it.

> I agree that there are several people on the list who want to do
>this, but I don't feel like there was any broad consensus reached. (I
>think that's actually true in general. None of the threads on this list
>so far has had the feel of a vote.)
>  
>
I agree.

>  
>
>>       (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
>>       want to do this.
>>
>>       (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
>>       values. (FBTYPE).  Do we need more discussion?
>>    
>>
>
>My understanding is that if we are trying to move iCalendar to draft
>standard status (which is what Lisa created this list for), then we
>can't add things; we can only clarify things, and remove the bits that
>aren't actually interoperably implemented.
>
>If our goal is broader than that, then we need to figure out what
>exactly our goal is, and what sort of backward-compatibility constraints
>we have. In particular, RFC 2445 says that TRANSP can be "OPAQUE" or
>"TRANSPARENT", and nothing else. So if we change that, would we have to
>change VERSION as well? Because that would suck.
>
VERSION is the version of the data format, not the contents. So no VERSION
would not have to change.

I think that CLASS needs to be deprecated completely. The resistance
to that idea seem to be to create new value types that have well
defined values. That would be my 2nd choice.

>  
>
>>       (1.1.4) 2445 - New VJOURNAL draft
>>    
>>
>
>Is there actually anyone who wants a new VJOURNAL draft? (As opposed to
>just dropping it.)
>
Let those that want VJOURNAL write the draft :-)
There are two products that I know of that use it.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms020809080001000205000006
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTE0MTk1NzMyWjAjBgkqhkiG9w0BCQQxFgQUTkWkyQ2Sw47OiZbvcGjE
7uJsDfMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAn6QEGGT36t++R4jfwtEaOIfRbeq8YBcKgLMfLLR+YfhN3POjVSXIXx9gjHAdr9Dm
10RuRvAia4mAjeNEkXVxoL093fC5tUdpiiQO4/VXSP15PrEc9buCGFa+2aYaWPUq3tfbl4IY
s6E8gNX32E2seybXYsMUbMAt8KAjekEXfCkTQkEfO1EWMcSzxVA1Guc6IA2zawje6hhI/6pU
dKjSGy0akG90I424+X9HXcx5GplIAiWGI9fTyqOf5tIK0Ge6QEpEY/QkF4Xp/dDUjbGFEFng
U6ePiiCx4ISVIY9wZh5eEtj6H1Ck5QjkI3XprGJeAc0wT3CQ61KWHUzObsDPMwAAAAAAAA==
--------------ms020809080001000205000006--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EJiOpo030609 for <[e-mail]>; Tue, 14 Sep 2004 12:44:24 -0700
Received: from cse.ucsc.edu (adsl-63-194-88-161.dsl.snfc21.pacbell.net [63.194.88.161]) by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id i8EJid0x005902; Tue, 14 Sep 2004 15:44:40 -0400
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 2004 12:44:38 -0700
From: Elias Sinderson <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
References: <[e-mail]>	<1094855069.6086.489.camel@dirk> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 19:44:25 -0000

Leo Sauermann wrote:

>> Also in the debate on this list was listing all entries in UTC [...]
>
> [...] I would recommend to always store time in local time format with 
> timezone

local to the client or local to the server? Assuming that you mean local 
to the client, this simply begs the question as to how one deals with:
* multiple clients in different timezones modifying the same calendar?
* a client, such as a cell phone, which moves between timezones?
Examples use cases provided upon request, there are many - I assume the 
reader can provide their own...

> because any UI (cell phone, whatever) then may display it without any 
> math.

The math consists of a single lookup and a single addition or 
subtraction, or the equivalent of a switch statement based on the 
current client timezone... Even cell phones can do that without 
difficulty, as can handhelds, etc.

Quite honestly, storing all times in UTC is the simplest solution. It is 
well within the extent of client capabilities to translate times from 
UTC to the local client setting. Further, this prevents servers from 
having to convert timezones for various clients in different timezones, 
makes the protocol easier to understand and, lastly, avoids unnecessary 
bloat on the wire.


Regards,
Elias


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EJU2pp026816 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Tue, 14 Sep 2004 12:30:03 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8EJTqSw007162 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 14 Sep 2004 12:29:54 -0700
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 2004 13:29:52 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020803030400020703070007"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 19:30:04 -0000

This is a cryptographically signed message in MIME format.

--------------ms020803030400020703070007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



[e-mail] wrote:

>
>
>Got to disagree with you Doug.  Unfortunately, the "replace all" set does
>not work with our product and interoperability testing (both external and
>internal) has shown that.
>
Odd. My testing with your product shows that it does work. Maybe we are not
talking the same thing.

(1) I send a REQUEST - you accept.
(2) I send another REQUES with updated information - you accept.

(1) has a UID of 'xxx', SEQ of 0
(2) Has a UID of 'xxx;  SEQ of 1

It works with your product - what does not work?

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms020803030400020703070007
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTE0MTkyOTUyWjAjBgkqhkiG9w0BCQQxFgQU0NRk//u0zcfiDQX8vgG7
IXFX5lUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAL1AARhA4nhWntY0qaZTZxqHigibIS4AN9hFsG+dh8OPA/4iFQ4OYrAbVXr09GMXn
1VE5tTpOO999XhNjixmcW5b15a/VxsTwK1+pPiOq7M7wofhuWoErasCsB48hJfgFBy2blRWv
dTxvTGbvbgQV2ssPRyuAIN4eepa7F5MfjYYB3RScxMLYChvYkl+k2jvdB4fKuucJB03zSEdi
6xv/Y8mYL47e94Lt+e/QXuz3zMbUFN2JT+xX3K2jb3KB7DabGRJlrRPCiAMsu/VGG48qV5Vv
GMw4KxAFL77RK0Qeinbfh218YKEyWrerZ0dFY2ec7Oj/j9pfi4KL/ga7a+X8ZAAAAAAAAA==
--------------ms020803030400020703070007--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EHw0po016026 for <[e-mail]>; Tue, 14 Sep 2004 10:58:00 -0700
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);  Tue, 14 Sep 2004 10:57:56 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 14 Sep 2004 10:57:39 -0700
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Sep 2004 10:57:56 -0700
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 10:57:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] Moderation in all things
Date: Tue, 14 Sep 2004 10:57:55 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] Moderation in all things
thread-index: AcSagF93RKO2arPrRwGr5S5rKSZJXAAAWtRg
From: "Cameron Stillion" <[e-mail]>
To: "Nathaniel Borenstein" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 14 Sep 2004 17:57:57.0085 (UTC) FILETIME=[5DA7B8D0:01C49A84]
X-Scanned-By: MIMEDefang 2.39
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i8EHw0po016026
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 17:58:01 -0000

As an interim co-chair and (therefore) default moderator of this list, I
want to thank Nathaniel for his reminder to all of us to keep our
discussion professional and kind.

When we invented the term "calsify", I volunteered to be a co-chair of
this working group, and our initial charter was agreed upon in our small
group to be this:

Simplify the existing iCal proposed standard (remove only - do not add)
to solve the confusion and interoperability headaches, with the ultimate
goal of bringing this new "simplified" iCal (eCal/sCal/...) to the state
of actual INTERNET STANDARD.

So far, our discussion has been focused on aspects of the spec which are
unclear and which are in need of simplification/clarification.  We have
identified many aspects which may need to be cut from the standard, and
many which may need to be less rigid, or more rigid.  We have also
identified good points for additions to a future standard, but which we
will not be pursuing in the context of this working group.  I fully
expect such ideas to spring from the current state of things.  

These have been by and large excellent, professional, and courteous
discussions.  LET'S KEEP IT THAT WAY.

Our ability to deliver on bringing calendaring to the internet with the
ubiquity of e-mail will largely depend on our ability to cooperate,
reason, and function as a group.  While opinions which runs contrary
about technical issues, schemas, functionality, scenarios, etc. are very
welcome - and will ultimately lead to a better standard... Opinions
which are aggressive or demeaning are NOT WELCOME, regardless of
intention.


cameron


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Nathaniel
Borenstein
Sent: Tuesday, September 14, 2004 10:28 AM
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be
allowed

On Sep 13, 2004, at 5:14 PM, Doug Royer wrote:

> That make no sense at all.

If one can't make sense of something, it is imprudent to assume that's
necessarily because it makes no sense.  The problem can be on either
end.

> At his point I am going to consider your posts as trolling.
>
> Does any one (else) have any input on this topic?

Yes, I do.  While I have no opinion either way about the details of this
disagreement, I want to say that I consider it completely unacceptable
to dismiss someone else's politely-expressed opinions with a pejorative
-- especially one that seems to make no sense in context.  
What on earth would Tom [Ramsdell] be "trolling" for?  Arguments for the
sake of arguments?

On Sep 13, 2004, at 8:08 PM, Mark Swanson wrote:

> I would like to know what the process is for moving forward on issues 
> like this.... (Surely not the same process as the previous 
> ietf-calendar mailing
> list?)

I think the very first deliverable of this list, which we/I have
neglected so far, should be a proposed charter for a new working group. 
  Once that is established, we will get working group chairs, who will
be responsible for such disputatious-issue resolution.  Until then, I
don't really expect controversial issues to be *resolved*, and I see the
purpose of the current preliminary discussion as exploring the issues
and discussing which ones we should *try* to resolve -- which,
coincidentally, involves basically the same questions as drafting a
charter.

On Sep 13, 2004, at 8:20 PM, Doug Royer wrote:

> So far only Robert seem to think that the method he proposes is 
> documented, standardized, or compatible with many others.

The fact that only one person (or a few) speaks out about either side of
an issue does NOT mean that whoever is most aggressive gets to declare a
consensus.  For my part, I haven't expressed an opinion because I don't
yet consider myself well-informed enough to have one, and was looking
forward to clarification, explanation, and persuasion.  
If I had to take sides in the absence of these, I would be 
instinctively inclined to take the side that's being most polite.   My 
preference, however, would be to see the issues sufficiently well
thought-out and clearly spelled-out that I could confidently reach my
own conclusion.

More philosophically, this attitude isn't just because I hate conflict
(although I do).  It's because I believe that when issues are really
well explored, they are much less likely to end up in flat-out
disagreements that *require* voting.  Although I didn't participate in
much of the long history of the calsch group, the resulting documents
certainly look to me like too many arguments were somehow settled before
they were well-enough understood, perhaps by a "tyranny of the loudest."
I would really like to make sure that doesn't happen here.

> He did the same thing on the other mailing list and caused months of 
> delay.

If you are conjecturing that delay is his motive, I can tell you, as his
coworker, that this is just incorrect.  So either one of you is simply
flat-out wrong -- in which case you should eventually be able to
persuade people like me -- or there are subtleties that are not being
properly addressed or elucidated in this discussion.

> Fortunately this mailing list is not "how can it be done", its "how do

> people do it".

This shows again why we need a clear charter -- for my part, I don't
think *either* of those characterize our goal very well, but I'm closer
to the former than the latter.

> I do not think that the issue is stalled. I think that it is fairly 
> clear

The debate is *obviously* stalled, however clear the issues may be to
you -- "stalled" and "clear to you" are not antonyms.

On Sep 14, 2004, at 10:45 AM, [e-mail] wrote:

> You just are too stubborn to admit it.

Sigh.  Can we please try to keep this list free of ad hominem attacks on
*both* sides?  -- Nathaniel



_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EHSbpo013089 for <[e-mail]>; Tue, 14 Sep 2004 10:28:37 -0700
Received: from [192.168.1.100] [66.82.50.1] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id A3FB3419010C; Tue, 14 Sep 2004 10:01:47 -0700
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Nathaniel Borenstein <[e-mail]>
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
Date: Tue, 14 Sep 2004 13:28:03 -0400
To: [e-mail]
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 17:28:38 -0000

On Sep 13, 2004, at 5:14 PM, Doug Royer wrote:

> That make no sense at all.

If one can't make sense of something, it is imprudent to assume that's 
necessarily because it makes no sense.  The problem can be on either 
end.

> At his point I am going to consider your posts as trolling.
>
> Does any one (else) have any input on this topic?

Yes, I do.  While I have no opinion either way about the details of 
this disagreement, I want to say that I consider it completely 
unacceptable to dismiss someone else's politely-expressed opinions with 
a pejorative -- especially one that seems to make no sense in context.  
What on earth would Tom [Ramsdell] be "trolling" for?  Arguments for 
the sake of arguments?

On Sep 13, 2004, at 8:08 PM, Mark Swanson wrote:

> I would like to know what the process is for moving forward on issues 
> like
> this.... (Surely not the same process as the previous ietf-calendar 
> mailing
> list?)

I think the very first deliverable of this list, which we/I have 
neglected so far, should be a proposed charter for a new working group. 
  Once that is established, we will get working group chairs, who will 
be responsible for such disputatious-issue resolution.  Until then, I 
don't really expect controversial issues to be *resolved*, and I see 
the purpose of the current preliminary discussion as exploring the 
issues and discussing which ones we should *try* to resolve -- which, 
coincidentally, involves basically the same questions as drafting a 
charter.

On Sep 13, 2004, at 8:20 PM, Doug Royer wrote:

> So far only Robert seem to think that the method he
> proposes is documented, standardized, or compatible with
> many others.

The fact that only one person (or a few) speaks out about either side 
of an issue does NOT mean that whoever is most aggressive gets to 
declare a consensus.  For my part, I haven't expressed an opinion 
because I don't yet consider myself well-informed enough to have one, 
and was looking forward to clarification, explanation, and persuasion.  
If I had to take sides in the absence of these, I would be 
instinctively inclined to take the side that's being most polite.   My 
preference, however, would be to see the issues sufficiently well 
thought-out and clearly spelled-out that I could confidently reach my 
own conclusion.

More philosophically, this attitude isn't just because I hate conflict 
(although I do).  It's because I believe that when issues are really 
well explored, they are much less likely to end up in flat-out 
disagreements that *require* voting.  Although I didn't participate in 
much of the long history of the calsch group, the resulting documents 
certainly look to me like too many arguments were somehow settled 
before they were well-enough understood, perhaps by a "tyranny of the 
loudest."  I would really like to make sure that doesn't happen here.

> He did the same thing on the other mailing list and caused months of 
> delay.

If you are conjecturing that delay is his motive, I can tell you, as 
his coworker, that this is just incorrect.  So either one of you is 
simply flat-out wrong -- in which case you should eventually be able to 
persuade people like me -- or there are subtleties that are not being 
properly addressed or elucidated in this discussion.

> Fortunately this mailing list is not "how can it be done", its "how do 
> people do it".

This shows again why we need a clear charter -- for my part, I don't 
think *either* of those characterize our goal very well, but I'm closer 
to the former than the latter.

> I do not think that the issue is stalled. I think that it is fairly 
> clear

The debate is *obviously* stalled, however clear the issues may be to 
you -- "stalled" and "clear to you" are not antonyms.

On Sep 14, 2004, at 10:45 AM, [e-mail] wrote:

> You just are too stubborn to admit it.

Sigh.  Can we please try to keep this list free of ad hominem attacks 
on *both* sides?  -- Nathaniel





X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EFeXpo032002 for <[e-mail]>; Tue, 14 Sep 2004 08:40:33 -0700
Received: by homer.w3.org (Postfix, from userid 13795) id C36EC4F144; Tue, 14 Sep 2004 11:40:32 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id C0F634F0FC; Tue, 14 Sep 2004 11:40:32 -0400 (EDT)
Date: Tue, 14 Sep 2004 11:40:32 -0400 (EDT)
From: Charles McCathieNevile <[e-mail]>
To: Leo Sauermann <[e-mail]>
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <1094855069.6086.489.camel@dirk> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.39
X-Mailman-Approved-At: Tue, 14 Sep 2004 09:57:06 -0700
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 15:40:34 -0000

On Tue, 14 Sep 2004, Leo Sauermann wrote:

>> Also in the debate on this list was listing all entries in UTC.  This
>> would eliminate the need for VTIMEZONE in many (all?) components.
>> Yet the CUA still needs to do TZ math.  So this is a proposal on
>> how to have simple IANA registered time zones so that everyone does
>> the same math.
>
>uhhh..
>many of todays calendars in VCAL have errors about timezones.
>If mozilla/kde/whatever doesn't get it, we rdf developers won't get it, too.
>
>so I would recommend to always store time in local time format with
>timezone, because any UI (cell phone, whatever) then may display it
>without any math.

You mean something like "2004-10-04T09:00 TZID=Hungary/Budapest" or something
equivalent? That's useful to have, but I don't think in real-world
applications you can get away with not being able to do the maths.

I have a cellphone and a laptop, and sync my calendars between them. I have
several problems:

Some events have a different timezone for the start and end (most often,
aeroplane flights - the data I get gives the departure and arrival times as
local to the relevant airport. This is indeed the most comfortable way I have
found to deal with it. So to work out how to block out the right times as
"you're on the plane - you can't meet anyone for lunch" I need to
convert the time zone when I am entering the data (which is a pain) or do the
maths dynamically (which is a pain, but only for the tool developer...)

recurrent events have their time specified in different time zones. For
instance I have one recurrent meeting with times expressed in France/Paris
time, and another expressed in US/Boston time. Since these recur, it isn't
such a pain to change the time zone when I put them in, so I enter each of
them having set the machine to the relevant time zone. But in synching and in
shifting time zone bases for my tools they need to do the calculations making
sure that they don't blindly convert Boston time to Paris time (for a week or
two most years the difference is an hour more or less than it is the other
50-odd weeks) and let me miss a meeting.

One-off Web events and the like are often specified in a local time based on
where the guy writing the page is. This seems reasonable. But if I have
to shift my software around to that timezone to enter the time, it's a pain,
and any given person is unlikely to specify things in lots of timezones.

I tried keeping one clock synched to UTC and doing everything based on that.
As someone who changes timezones on average more than once a week I thought
it would make sense, but it doesn't. The maths is a bit more complex than
straight addition/subtraction, but not very. Most of the complexity is to do
with looking up tables. That sounds to me like the kind of maths that we
should rely on computers to do, since they are less likely to miss planes if
we think carefully three times and measure twice before we cut the code
(sorry to mix a carpenters metaphor) than if I have to continually do this...

cheers

Chaals



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EF3Rpo020098 for <[e-mail]>; Tue, 14 Sep 2004 08:03:28 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 8ABA828490B for <[e-mail]>; Tue, 14 Sep 2004 17:03:01 +0200 (CEST)
Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id 45DC4282FB9 for <[e-mail]>; Tue, 14 Sep 2004 17:03:01 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] List issues so far.
Date: Tue, 14 Sep 2004 17:03:21 +0200
To: [e-mail]
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 15:03:29 -0000

On Sep 14, 2004, at 16:57, Dan Winship wrote:
>>        (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
>>        want  to  do this
>
> Really? I agree that there are several people on the list who want to 
> do
> this, but I don't feel like there was any broad consensus reached. (I
> think that's actually true in general. None of the threads on this list
> so far has had the feel of a vote.)

Isn't it impossible to change all times to Z unless there is a solution 
for embeddding the timezone or the timezone rule in calculated 
recurring events? (which I would like to see).

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EF0Vpo019724 for <[e-mail]>; Tue, 14 Sep 2004 08:00:31 -0700
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 14 Sep 2004 11:01:24 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 09/14/2004 10:57:36 AM
Content-Type: multipart/mixed; boundary="=_mixed 00524DDA85256F0F_="
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 15:00:32 -0000

This is a multi-part message in MIME format...

--=_mixed 00524DDA85256F0F_=
Content-Type: multipart/alternative;
	boundary="----------=_1095174032-11730-130"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095174032-11730-130
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

doug wrote
>>I would propose that we (I'll volunteer) to setup some free testing.
>>Not sure what we need yet.  The results of the commercial testing
>>have not yet been provided.

Making your product the test for STANDARD is very strange since you seem 
to have a non-standard implementation.




Doug Royer <[e-mail]> 
Sent by: [e-mail]
09/13/2004 09:29 PM
Please respond to
[e-mail]


To
[e-mail]
cc

Subject
Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed








So far this is no WG - this is just a mailing list.

The IETF has an ISSUE page/tool , I think that we should use that.

People will need to write drafts, submit them, and get feedback. That
is the process. Until there is a draft, there is nothing do decide.

A simple typo will be noteworthy, but not that relevant as there
will be new drafts written that may take some of the existing text.
A typo list can be used to verify the same mistakes are not taken again.

Another problem is that the compatibly testing has been very limited
so far. A small handful of vendor that could afford to pay the price
to attend is far from an exhaustive compatibility testing.

 I would propose that we (I'll volunteer) to setup some free testing.
Not sure what we need yet.  The results of the commercial testing
have not yet been provided.


Mark Swanson wrote:

>Thanks for the response.
>
>However, I really am wondering what the process is. For example, in the 
>simplest case where we want to fix a 2445 typo and we all agree. Is there 
a 
>person or group that will maintain _the_ fix list that will be accepted 
by 
>the IETF. Or is the list simply to be maintained ad-hoc by the people on 
the 
>mailing list. Or, what... ? I seem to have missed the memo.
>
>Thanks.
>
> 
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


------------=_1095174032-11730-130--

--=_mixed 00524DDA85256F0F_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
AQAAoIINcDCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZI
hvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4
MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rI
SsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+
MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG
+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY
UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5Jz
dC6JOzUTcudAMZrTssSr51a+i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBB
MPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQwHhcNMDQwOTAzMDAwMDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91
ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMWHYQKNX06SDOZPZvQOVD5lgC
2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4IaamL0bbVrINBtK
mW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo
0Y6uq+kkkPqYd+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQz
FWwe1UaHKYPb8d8xO6qGJNisRNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IH
nwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJBgNVHRMEAjAAMIGsBgNVHSAE
gaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM26zHybGdD0C7c
Q+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J3
8rgwggUBMIIEaqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEB
BAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAw
MFoXDTA1MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B
CQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAzFh2ECjV9OkgzmT2b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUE
k1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSpluabeSeXZhFTAZSp7mqR8kZM55
LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ+SIZOInZLPfU
iloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETS
N4vU/WT1Pv+IAvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IB
HDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT
aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcE
BhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp
4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPrGpYuUwn62iMbUSaGXYFlg0Am
2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOSzi6mbsF7ZSIc
2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wCQYF
Kw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTE0MDEyOTIwWjAjBgkqhkiG9w0BCQQxFgQU9D4ZXTPA
f4+SW/gvPadPBVk/1hEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90
IFZhbGlkYXRlZAIQV2Y2bnhVsEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsx
geSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg
U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wDQYJKoZIhvcNAQEBBQAEggEAAt8SgxRdf3+J2woOp4pg8rXqoDgC
o9bpDUCVACPjhzscN27AVnNC641RJwKcNQ0U1Bbzz87xkQ1en7el3X8jU/1s
7dD6xwDkng9NBS6n3u24m57pLnlW72/8Sbk65wCPZOP+bZMlDIzY2lSpMMUC
TOEzRX4oc1VGTZvmlgJQM9g1sv83UqQ3i5w0Eg2dkFJnLV2QnefavA6pSPno
DF6h+9Eywuk031UkQVzx0W80vjL4WpBsD/bUi96cbNsw2vVBkUGVXelxkyP3
oNhi4CQtz3HB2qkP50QpNuBQhMXKMhONkTn6FdlFZ22f08OUOHzVm/bxEAyx
D7tk9HBcikVtwwAAAAAAAA==

--=_mixed 00524DDA85256F0F_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EErVpo017719 for <[e-mail]>; Tue, 14 Sep 2004 07:53:31 -0700
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 14 Sep 2004 10:54:21 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 09/14/2004 10:50:36 AM
Content-Type: multipart/mixed; boundary="=_mixed 0051A89385256F0F_="
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 14:53:31 -0000

This is a multi-part message in MIME format...

--=_mixed 0051A89385256F0F_=
Content-Type: multipart/alternative; boundary="----------=_1095173611-11730-84"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095173611-11730-84
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

There is a very good example of multiple BEGIN VEVENT/ END VEVENT inside 
one VCalendar stream.
I have an already existing repeating meeting.  Several of the future 
events have had there addenda updated and or there times modified.
A new person joins the team.  I now want to invite that person to the 
entire set.
I have to send the Original Rule plus additional BEGIN/END VEVENTS for the 
instances that have been  changed.




Doug Royer <[e-mail]> 
Sent by: [e-mail]
09/13/2004 09:14 PM
Please respond to
[e-mail]


To
[e-mail]
cc

Subject
[Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?







I think its a new issue.

When transferring only booked entries one begin/end works.

However METHOD is global to BEGIN/END VCALENDAR and
you can not have a single BEGIN/END VCALENDAR that
contains more than one METHOD value type.

So, if you are transporting more than one METHOD,
you MUST use multiple BEGIN/END VCALENDAR objects.

iMIP  enforces only one METHOD per MIME object.
So you can not transfer an entire calendar in
one iMIP MIME object anyway.

CAP has a VCALSTORE component that can encapsulate
many VCALENDAR objects as a way to solve that problem.

Do we want to create a wrapper object (VCALSTORE?) so that
we can transfer multiple METHOD VCALENDAR objects?

If not, then implementations that do not accept multiple BEGIN/END
vcalendar objects can not transfer any iTIP object that might be
in a calendar in a single transfer.

Not an answer - just some info...

The question we need to ask is:

    Do we want to be able to transfer 'sync' an entire calendar in one 
pass?

If yes, then we have to allow multiple BEGIN/END per transfer.

I think the answer is yes.

Oren Sreebny wrote:

>Does 1.1.1 include this issue?
>
>----------------------
>
>2445 says that "The Calendaring and Scheduling Core
>Object is a collection of calendaring and scheduling information.
>Typically, this information will consist of a single iCalendar object.
>However, multiple iCalendar objects can be sequentially grouped 
together."
>
>But implementations don't all support multiple VCALENDAR blocks - for
>instance, in Oracle Cal when you export iCalendar data it surrounds  each
>VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither Apple's iCal
>nor Outlook will accept that as an import format - they want all the
>VEVENTs grouped within a single VCALENDAR block.
>
>Or is this a new issue?
> 
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


------------=_1095173611-11730-84--

--=_mixed 0051A89385256F0F_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
AQAAoIINcDCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZI
hvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4
MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rI
SsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+
MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG
+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY
UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5Jz
dC6JOzUTcudAMZrTssSr51a+i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBB
MPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQwHhcNMDQwOTAzMDAwMDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91
ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMWHYQKNX06SDOZPZvQOVD5lgC
2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4IaamL0bbVrINBtK
mW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo
0Y6uq+kkkPqYd+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQz
FWwe1UaHKYPb8d8xO6qGJNisRNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IH
nwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJBgNVHRMEAjAAMIGsBgNVHSAE
gaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM26zHybGdD0C7c
Q+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J3
8rgwggUBMIIEaqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEB
BAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAw
MFoXDTA1MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B
CQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAzFh2ECjV9OkgzmT2b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUE
k1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSpluabeSeXZhFTAZSp7mqR8kZM55
LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ+SIZOInZLPfU
iloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETS
N4vU/WT1Pv+IAvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IB
HDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT
aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcE
BhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp
4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPrGpYuUwn62iMbUSaGXYFlg0Am
2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOSzi6mbsF7ZSIc
2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wCQYF
Kw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTE0MDExNDQxWjAjBgkqhkiG9w0BCQQxFgQUzJ/p8eeT
G5NSgz2b3c+Qxzogr0owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90
IFZhbGlkYXRlZAIQV2Y2bnhVsEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsx
geSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg
U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wDQYJKoZIhvcNAQEBBQAEggEAiyaRFydgdE5pmnMJLS9eZGv6c/SX
1GgczGYZv2oU/2uylYCQ/DsifrctlBphA6i2qOzeGe5S9rXD4CEtSoUFysw5
yq0fHdlhOerLljO9wIguL6tD1FdALPOsYG+vokO/weMmJNDy1YRhg93mi+Jm
oZ+VeBrLolIURG4xahKR8K0fNf3p1v6iE1qyjhU6ci91TvB/rlTVgXTyZOmW
KDBvR0nRIwWoZvOX2nmboLGffwInYu6hjchJ+Dod27hkMTlWrZOaSmwGp8/a
reJZxllSE0GCp8HD6gJ9MHqKZ7zUW4k09iZDKFeIXW4lwaluJMusiwnGcxEf
vV4BHpKWRZyADAAAAAAAAA==

--=_mixed 0051A89385256F0F_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EEplpp016589 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 14 Sep 2004 07:51:48 -0700
Received: (qmail 30660 invoked from network); 14 Sep 2004 14:51:42 -0000
Received: from localhost (HELO twelve-monkeys.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 14 Sep 2004 14:51:42 -0000
Subject: Re: [Ietf-calsify] List issues so far.
From: Dan Winship <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Tue, 14 Sep 2004 10:57:29 -0400
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.94.1 
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 14:51:49 -0000

On Mon, 2004-09-13 at 17:18 -0600, Doug Royer wrote:
>        (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
>        that allows this.  Deprecate it?

You need BYSETPOS to say "the first/last weekday of the month", which I
think is supported by more than one CUA.

>        (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
>        want  to  do this

Really? I agree that there are several people on the list who want to do
this, but I don't feel like there was any broad consensus reached. (I
think that's actually true in general. None of the threads on this list
so far has had the feel of a vote.)

>        (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
>        want to do this.
> 
>        (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
>        values. (FBTYPE).  Do we need more discussion?

My understanding is that if we are trying to move iCalendar to draft
standard status (which is what Lisa created this list for), then we
can't add things; we can only clarify things, and remove the bits that
aren't actually interoperably implemented.

If our goal is broader than that, then we need to figure out what
exactly our goal is, and what sort of backward-compatibility constraints
we have. In particular, RFC 2445 says that TRANSP can be "OPAQUE" or
"TRANSPARENT", and nothing else. So if we change that, would we have to
change VERSION as well? Because that would suck.

>        (1.1.4) 2445 - New VJOURNAL draft

Is there actually anyone who wants a new VJOURNAL draft? (As opposed to
just dropping it.)

-- Dan




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EEiSpo014265 for <[e-mail]>; Tue, 14 Sep 2004 07:44:28 -0700
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 14 Sep 2004 10:45:22 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 09/14/2004 10:41:33 AM
Content-Type: multipart/mixed; boundary="=_mixed 0050D5EF85256F0F_="
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 14:44:28 -0000

This is a multi-part message in MIME format...

--=_mixed 0050D5EF85256F0F_=
Content-Type: multipart/alternative; boundary="----------=_1095173068-11730-55"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095173068-11730-55
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

Doug you asked for clarification from original authors on that issue. They 
came down on ,my side of argument.  You just are too stubborn to admit it.



Doug Royer <[e-mail]> 
Sent by: [e-mail]
09/13/2004 08:20 PM
Please respond to
[e-mail]


To
[e-mail]
cc

Subject
Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed







So far only Robert seem to think that the method he
proposes is documented, standardized, or compatible with
many others.

He did the same thing on the other mailing list and caused
months of delay. I have found over 40 ical products that
can not use that method. Fortunately this mailing list is
not "how can it be done", its "how do people do it".

And currently the vast majority of products simply
replace the objects during an update keeping the same UID.

I do not think that the issue is stalled. I think
that it is fairly clear - replacing the objects
with an entire updated set with the same UID
works with all vendors (including the one that Roberts
company ships) I can find. Robert does not seem to
dispute this, he simply wants everyone to also do
it the 2nd way - and they do not.


>I would like to know what the process is for moving forward on issues 
like 
>this. I received a description of this mailing list's purpose but that's 
>about it. If a more detailed description of how conflicts are to be 
resolved 
>and how decisions are actually going to be made is available please point 
me 
>to it. (Surely not the same process as the previous ietf-calendar mailing 

>list?)
>
>Thank you.
>
> 
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


------------=_1095173068-11730-55--

--=_mixed 0050D5EF85256F0F_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
AQAAoIINcDCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZI
hvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4
MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rI
SsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+
MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG
+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY
UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5Jz
dC6JOzUTcudAMZrTssSr51a+i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBB
MPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQwHhcNMDQwOTAzMDAwMDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91
ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMWHYQKNX06SDOZPZvQOVD5lgC
2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4IaamL0bbVrINBtK
mW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo
0Y6uq+kkkPqYd+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQz
FWwe1UaHKYPb8d8xO6qGJNisRNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IH
nwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJBgNVHRMEAjAAMIGsBgNVHSAE
gaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM26zHybGdD0C7c
Q+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J3
8rgwggUBMIIEaqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEB
BAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAw
MFoXDTA1MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B
CQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAzFh2ECjV9OkgzmT2b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUE
k1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSpluabeSeXZhFTAZSp7mqR8kZM55
LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ+SIZOInZLPfU
iloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETS
N4vU/WT1Pv+IAvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IB
HDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT
aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcE
BhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp
4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPrGpYuUwn62iMbUSaGXYFlg0Am
2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOSzi6mbsF7ZSIc
2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wCQYF
Kw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTE0MDAyMDIxWjAjBgkqhkiG9w0BCQQxFgQUapwWn1ep
AaLdFJn8c41iWsIEbH8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90
IFZhbGlkYXRlZAIQV2Y2bnhVsEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsx
geSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg
U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wDQYJKoZIhvcNAQEBBQAEggEAWY/aLC94E0LfAW3SD9PILt8zllI7
g1tuB7FWLaeJk6760EQeDv1l5zfspZo822d5/NapbrlQyq5hOkbg/7ZihCUK
ymJKMC8O0EHUaqjDrk09dLDpPfxNicVG1doX8R+zyLqy44+RAH5SJDIAlUgt
4XJJU9tRfLij9vRPzo3ueNHuKjF+xeRYh5npFWkWMRSNWs1QBnuyYx/fOGdu
x8P1KWuQzu64+JrLacAL2iJb+ITZ1M/On4EuU/IcQfUPP4gu9a1iLjKGVh8m
nuPK75I2glAS/OU+CsEKppdX05ItA1IYDZ2LjV4V50/23U7kA+BFSo9F2uyI
2tRr01Nyt8HWzAAAAAAAAA==

--=_mixed 0050D5EF85256F0F_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mailgate1.uni-kl.de (mailgate1.uni-kl.de [131.246.120.5]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EEfTpp013552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Sep 2004 07:41:31 -0700
Received: from dfki-2203.dfki.uni-kl.de (isg-200.dfki.uni-kl.de [131.246.241.120]) by mailgate1.uni-kl.de (8.12.10/8.12.10) with ESMTP id i8EEfShr017236;  Tue, 14 Sep 2004 16:41:28 +0200
Received: from serv-4100.kl.dfki.de (serv-4100.kl.dfki.de [192.168.41.180]) by dfki-2203.dfki.uni-kl.de (8.11.7p1+Sun/8.11.4) with ESMTP id i8EEfRt04008; Tue, 14 Sep 2004 16:41:27 +0200 (MEST)
Received: from [192.168.22.92] (vpn-2242.kl.dfki.de [192.168.22.92]) by serv-4100.kl.dfki.de (8.11.7p1+Sun/8.11.7) with ESMTP id i8EEfQm11524; Tue, 14 Sep 2004 16:41:27 +0200 (MEST)
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 2004 16:41:25 +0200
From: Leo Sauermann <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
References: <[e-mail]> <1094855069.6086.489.camel@dirk> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.39
X-Mailman-Approved-At: Tue, 14 Sep 2004 09:57:06 -0700
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 14:41:32 -0000

>
> Also in the debate on this list was listing all entries in UTC.  This
> would eliminate the need for VTIMEZONE in many (all?) components.
> Yet the CUA still needs to do TZ math.  So this is a proposal on
> how to have simple IANA registered time zones so that everyone does
> the same math.

uhhh..
many of todays calendars in VCAL have errors about timezones.
If mozilla/kde/whatever doesn't get it, we rdf developers won't get it, too.

so I would recommend to always store time in local time format with 
timezone, because any UI (cell phone, whatever) then may display it 
without any math.

regards
Leo



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EEdepo012939 for <[e-mail]>; Tue, 14 Sep 2004 07:39:40 -0700
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] List issues so far.
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 14 Sep 2004 10:40:25 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 09/14/2004 10:36:45 AM
Content-Type: multipart/mixed; boundary="=_mixed 005061FC85256F0F_="
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 14:39:41 -0000

This is a multi-part message in MIME format...

--=_mixed 005061FC85256F0F_=
Content-Type: multipart/alternative; boundary="----------=_1095172780-11730-20"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095172780-11730-20
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

microsoft uses setpos when repeat is 4 monday of month



Doug Royer <[e-mail]> 
Sent by: [e-mail]
09/13/2004 07:18 PM
Please respond to
[e-mail]


To
[e-mail]
cc

Subject
[Ietf-calsify] List issues so far.







       List if ideas (in random order) on this list.

       (1). 2445 - (iCAL) Changes and fixes.

       (1.1) 2445 - Split into separate drafts

       This allows for separation of topics and allows each to make
       it or not to standard.

       (1.1.1) 2445 - Basic which includes VEVENT

       (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.

       (1.1.2) 2445 - Simplify recursions.  I think we are  saying  we
       want to do this, we need a more specific proposal.

       (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
       are saying  want  to  do  this,  we  need  a  more  specific
       proposal.

       (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
       that allows this.  Deprecate it?

       (1.1.2.3) 2445 - No more than one RRULE per component?  I think
       we  are  saying  we want to do this, we need a more specific
       proposal.

       (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
       want  to  do this, we need a more specific proposal and will
       involve time zone data being evaluated at CUA only.

       (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
       want to do this.

       (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
       values. (FBTYPE).  Do we need more discussion?

       (1.1.2.7) 2445 - ALTREP  I do not think  we  have  proven  that
       this is a compatibility issue as a CUA can or can not use it
       and it does not effect the data or flow of data.  CUAs  that
       can  not  display  the  data  ignore it anyway.  Having this
       property does not break CUAs that do not use it.   How  many
       use this?

       (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
       this is a compatibility issue as a CUA can or can not use it
       and it does not effect the data or flow of data.  Thin CUA's
       can not use it anyway and ignore it.  Having  this  property
       does  not break CUAs that do not use it.  How many use this?

       This eliminates the need to send VTIMEZONE.

       (1.1.2.9) 2445 - Deprecate properties

       (1.1.2.9.1) 2445 - GEO  I think we are saying NO, however  only
       GREGORIAN in scope at this time.

       (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.

       (1.1.2.9.3) 2445 - CLASS   I  think  we agree that the current
       undefined  meaning  must  be  deprecated  as  there  is   no
       interoperability.

       (1.1.2.9.4) 2445 - New CLASS  There seems to be a strong desire
       to keep this.  See "Access Control" below.

       (1.1.3) 2445 - New VTODO draft

       (1.1.4) 2445 - New VJOURNAL draft

       (1.1.5) 2445 - NEW VALARM draft  Need to define  when  to  send
       them.  Need an exhaustive discussion.

       (1.1.6) 2445  - How  to  handle  time  zones in CUAs.  I have a
       proposal on new time zone format for CUAs  to  share  common
       time zone data.  Need more feedback.



       (2) 2446 - (iTIP) Changes and fixes.

       (2.1) 2446 - Simplify updates - settle on one way



       (3) 2447 - (iMIP) Changes and fixes.

       (3.1) 2447 - Specify minimum  MIME support needed


       (4)  New - Access Control

       The  access  control  over  iMIP  is not the same as access
       control needed for client/server transport of objects.  Need
       to define and document.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


------------=_1095172780-11730-20--

--=_mixed 005061FC85256F0F_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
AQAAoIINcDCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZI
hvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4
MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rI
SsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+
MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG
+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY
UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5Jz
dC6JOzUTcudAMZrTssSr51a+i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBB
MPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQwHhcNMDQwOTAzMDAwMDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91
ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMWHYQKNX06SDOZPZvQOVD5lgC
2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4IaamL0bbVrINBtK
mW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo
0Y6uq+kkkPqYd+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQz
FWwe1UaHKYPb8d8xO6qGJNisRNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IH
nwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJBgNVHRMEAjAAMIGsBgNVHSAE
gaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM26zHybGdD0C7c
Q+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J3
8rgwggUBMIIEaqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEB
BAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAw
MFoXDTA1MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B
CQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAzFh2ECjV9OkgzmT2b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUE
k1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSpluabeSeXZhFTAZSp7mqR8kZM55
LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ+SIZOInZLPfU
iloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETS
N4vU/WT1Pv+IAvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IB
HDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT
aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcE
BhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp
4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPrGpYuUwn62iMbUSaGXYFlg0Am
2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOSzi6mbsF7ZSIc
2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wCQYF
Kw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMjMxODI1WjAjBgkqhkiG9w0BCQQxFgQU5oAeTBJ1
GwPEfiVw72Ybxc7C0IQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90
IFZhbGlkYXRlZAIQV2Y2bnhVsEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsx
geSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg
U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wDQYJKoZIhvcNAQEBBQAEggEAdT+lEBl4K4TE/7hFLgsmQqFguODW
YURrhupek2qkZQDrrsNbT/U0Mo/HMnMLtyb8WHA5Po0Mk4CE5tOE1pSK2F6N
7B3VUbmjwAgsgIER0TUQWoETBr5fqMsm0CmhoI1I2Xx+WaGFqX6JYNzzEBNI
9GtLIurH4QzPk7pa+tDDbkDBRAnJVHqUggmUKdOxXesBulFipluAgm9iNCiE
WPxGd3HWEfaEFuRzxZoTALWQl/u0P3U3pdpTN3fM9xnO/ToR812K15M/KkEP
Z2bYNK9WT4n9yAcn/BelnJaiVBFCxWoZPR2sHOKLNbGjj9KJax2fA6EKd+YY
sNuz6afvcHqlWAAAAAAAAA==

--=_mixed 005061FC85256F0F_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EEWApo012349 for <[e-mail]>; Tue, 14 Sep 2004 07:32:10 -0700
In-Reply-To: <[e-mail]>
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
To: [e-mail]
X-Mailer: Lotus Notes Build V70_09082004NP September 08, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 14 Sep 2004 10:23:36 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 09/14/2004 10:29:15 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 14:32:11 -0000

Got to disagree with you Doug.  Unfortunately, the "replace all" set does
not work with our product and interoperability testing (both external and
internal) has shown that.

We're trying to find a middle ground so that we can consume this if we
receive it and it may or may not be an issue about the standard per se, but
what concerns me is that our implementation is vastly different (when
talking recurring reschedules) from other vendors, yet we all believe that
we follow the ical standard in our products.  So there's probably something
amiss with recurring reschedules in the proposed icalendar standard.

I think we should discuss this further in an open manner.  Does anyone else
have issues with recurring reschedules?
-CS


[e-mail] wrote on 09/13/2004 08:20:20 PM:

>
> So far only Robert seem to think that the method he
> proposes is documented, standardized, or compatible with
> many others.
>
> He did the same thing on the other mailing list and caused
> months of delay. I have found over 40 ical products that
> can not use that method. Fortunately this mailing list is
> not "how can it be done", its "how do people do it".
>
> And currently the vast majority of products simply
> replace the objects during an update keeping the same UID.
>
> I do not think that the issue is stalled. I think
> that it is fairly clear - replacing the objects
> with an entire updated set with the same UID
> works with all vendors (including the one that Roberts
> company ships) I can find. Robert does not seem to
> dispute this, he simply wants everyone to also do
> it the 2nd way - and they do not.
>
>
> >I would like to know what the process is for moving forward on issues
like
> >this. I received a description of this mailing list's purpose but that's

> >about it. If a more detailed description of how conflicts are to
beresolved
> >and how decisions are actually going to be made is available pleasepoint
me
> >to it. (Surely not the same process as the previous ietf-calendar
mailing
> >list?)
> >
> >Thank you.
> >
> >
> >
>
> --
>
> Doug Royer                     |   http://INET-Consulting.com
> -------------------------------|-----------------------------
> [e-mail]                 | Office: [phone]
> http://Royer.com/People/Doug   | Fax:    [phone]
>                                | Cell:   [phone]
>
>               We Do Standards - You Need Standards
>
>
> [attachment "smime.p7s" deleted by Chris Stoner/Westford/IBM]
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EDxapp009952 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Tue, 14 Sep 2004 06:59:37 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8EDxQSw002380 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 14 Sep 2004 06:59:27 -0700
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 2004 07:59:25 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070804090906050901020201"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 13:59:38 -0000

This is a cryptographically signed message in MIME format.

--------------ms070804090906050901020201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Cameron Stillion wrote:

>I agree with the question...
>
>  
>
>>The question we need to ask is:
>>
>>   Do we want to be able to transfer 'sync' an entire calendar in one
>>    
>>
>pass?
>  
>
>>If yes, then we have to allow multiple BEGIN/END per transfer.
>>    
>>
>
>But I disagree with your reasoning.
>
>Transferring an entire calendar in one pass - does not seem to require
>more than one METHOD. If I am publishing an entire calendar, then I have
>one VCALENDAR with METHOD=PUBLISH.  If I am sending a request for you to
>attend a whole calendar's worth of meetings, then I presume I have one
>VCALENDAR with METHOD=REQUEST. 
>
That is one mode of using calendars.

The other is that the data transfer -into- the calendar is automatic.
And the CUA reads from the calendar. For example it is possible
for iTIP REQUESTS to be stored in the CS until processed by the CUA.

Those are client/server CUA/CS's. They must transfer all iTIP methods
objects to/from the CS.  So if you send me a REQUEST, it will be stored
in my calendar, even when my CUA is not running. Later when I start
my CUA it will load my calendar (PUBLISH/REQUEST/ADD/whatever).

Those are the requirements for client/server implementations.

This is not an issue for  iMIP-CUA's as iMIP only allows one METHOD
per object anyway..  For non-iMIP CUAs this will be an issue. Both
models exists. CalDav looks to be a client/server model also.

Ether way it still does not solve the problem that some (1?) 
implementation(s)
split each VEVENT into a separate VCALENDAR objects, even when
all of the METHOD values are the same.

Or is it that only one implementation can not handle multiple BEGIN/END
VCALENDAR even when all have the same METHOD value ?

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms070804090906050901020201
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTE0MTM1OTI1WjAjBgkqhkiG9w0BCQQxFgQUS6APCigMenoTGj3CdWs9
eYSCTeEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAfVBNLgoKqRObuds9lgSZte4TjfE3taRGFNP2ziFcMchQPhapmb+kl89EDmLFU8RK
Y+dF0Wpv7JN9NGmHzu+sEbkzFrBBysOcgES5aBcrcTcIzrDs6q/C7APTYLkqFYR+4KuMq9DJ
aYQUxA9gtq34KmQxCXk052iLTdp5shST2YuXENpAw74EaGCaxPnbNoGPJF9Qri07NNkOUT/m
+AyIyTBKDceFUsl6s/aA6xTjd8RpUYpyymwjNeyijeeenB1P9uQ+VilKAnRhyMMTDYWzQ4SB
uL5iHZv8r2RGVQJkdW1ufWF7CAUCIacHixu4giQna48h8qE9yjnQURF7o9GPiQAAAAAAAA==
--------------ms070804090906050901020201--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EDiSpp005679 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Tue, 14 Sep 2004 06:44:29 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8EDiISw002089 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 14 Sep 2004 06:44:20 -0700
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 2004 07:44:18 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] List issues so far.
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090600000501010306050700"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 13:44:30 -0000

This is a cryptographically signed message in MIME format.

--------------ms090600000501010306050700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



[e-mail] wrote:

>
> As for synchronization, none of the RFCs nor CAP name that as a 
> purpose, and I think we ought not to get into synchronizing endpoints 
> too much - not only for simplification reasons, but because many have 
> adopted SyncML as a standard and we don't need another one.

It was in the CAP requirements, original copy at:

    http://INET-Consulting.com/draft-ietf-calsch-capreq-04.txt

And it is on the calsch.org web site (at least it used to be).

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms090600000501010306050700
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTE0MTM0NDE4WjAjBgkqhkiG9w0BCQQxFgQU6YIF/CeBij2eXrPuBqWy
cDFlr/8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAoxKlZGcdErAvusZrFepJUj6hcHiGtTQ9Dw2gKfEn3Sdi7kfXJQq5vXCRezyhmEc7
m/J6XMf+wfNgVuEXcsrGrwOjZEiKMj6u5bK1a02rFf70HPutVT5lEirPe91iRUX3uzSEs9kC
aDi7Ez32j782AGLGbG3aM6zp9gq6yGE7NMjS/PuoOy1ty/mdDf+CvmGINxeNxYfMsbQd5Ii9
VcHnwIfNxkF6o3k8/oV4mA9rNdDRPd1krGLVWcCsncSXXxUVC2snBDPADgz6cDOr8P5NZ7Hz
KeLwrmL9a6wwakl77K1PvaTXhxzJdm0DTO2c55s7OYL0ie52Nst+TBSMeOAA9QAAAAAAAA==
--------------ms090600000501010306050700--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8E3I7po002938 for <[e-mail]>; Mon, 13 Sep 2004 20:18:07 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc11) with SMTP id <2004091403175901100olq5de> (Authid: TimHare); Tue, 14 Sep 2004 03:17:59 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Mon, 13 Sep 2004 23:15:58 -0400
To: [e-mail]
From: [e-mail]
Subject: Re: [Ietf-calsify] List issues so far.
In-Reply-To: <[e-mail] al>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 03:18:08 -0000

For simplification of transport between endpoints, I think the way that it 
is now is the simplest:
one object beginning with BEGIN:VCALENDAR and ending with END:VCALENDAR, 
everything within those bookends being processed by the same method.

If the object of 'send an entire calendar' is  'send all of the calendar 
objects in their current state', then METHOD:PUBLISH should suffice, 
although perhaps some might want to rename it to METHOD:STORETHISSTUFF 
.  All other METHODs seem to me to be intended to effect a change in a 
calendar. For that reason, I would, if I were writing a client, want to 
receive those in a separate transmission, or at least a separate MIME 
object if I'm receiving them via iMIP. Also remember that the order they're 
received in matters, you can't change an object you haven't received yet.

As for synchronization, none of the RFCs nor CAP name that as a purpose, 
and I think we ought not to get into synchronizing endpoints too much - not 
only for simplification reasons, but because many have adopted SyncML as a 
standard and we don't need another one.

At 08:31 PM 9/13/04, Oren Sreebny wrote:
>Does 1.1.1 include this issue?
>
>----------------------
>
>2445 says that "The Calendaring and Scheduling Core
>Object is a collection of calendaring and scheduling information.
>Typically, this information will consist of a single iCalendar object.
>However, multiple iCalendar objects can be sequentially grouped together."
>
>But implementations don't all support multiple VCALENDAR blocks - for
>instance, in Oracle Cal when you export iCalendar data it surrounds  each
>VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither Apple's iCal
>nor Outlook will accept that as an import format - they want all the
>VEVENTs grouped within a single VCALENDAR block.
>
>Or is this a new issue?
>
>- Oren
>
>
>On Mon, 13 Sep 2004, Doug Royer wrote:
>
> >
> >        List if ideas (in random order) on this list.
> >
> >        (1). 2445 - (iCAL) Changes and fixes.
> >
> >        (1.1) 2445 - Split into separate drafts
> >
> >        This allows for separation of topics and allows each to make
> >        it or not to standard.
> >
> >        (1.1.1) 2445 - Basic which includes VEVENT
> >
> >        (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.
> >
> >        (1.1.2) 2445 - Simplify recursions.  I think we are  saying  we
> >        want to do this, we need a more specific proposal.
> >
> >        (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
> >        are saying  want  to  do  this,  we  need  a  more  specific
> >        proposal.
> >
> >        (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
> >        that allows this.  Deprecate it?
> >
> >        (1.1.2.3) 2445 - No more than one RRULE per component?  I think
> >        we  are  saying  we want to do this, we need a more specific
> >        proposal.
> >
> >        (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
> >        want  to  do this, we need a more specific proposal and will
> >        involve time zone data being evaluated at CUA only.
> >
> >        (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
> >        want to do this.
> >
> >        (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
> >        values. (FBTYPE).  Do we need more discussion?
> >
> >        (1.1.2.7) 2445 - ALTREP  I do not think  we  have  proven  that
> >        this is a compatibility issue as a CUA can or can not use it
> >        and it does not effect the data or flow of data.  CUAs  that
> >        can  not  display  the  data  ignore it anyway.  Having this
> >        property does not break CUAs that do not use it.   How  many
> >        use this?
> >
> >        (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
> >        this is a compatibility issue as a CUA can or can not use it
> >        and it does not effect the data or flow of data.  Thin CUA's
> >        can not use it anyway and ignore it.  Having  this  property
> >        does  not break CUAs that do not use it.  How many use this?
> >
> >        This eliminates the need to send VTIMEZONE.
> >
> >        (1.1.2.9) 2445 - Deprecate properties
> >
> >        (1.1.2.9.1) 2445 - GEO  I think we are saying NO, however  only
> >        GREGORIAN in scope at this time.
> >
> >        (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.
> >
> >        (1.1.2.9.3) 2445 - CLASS   I  think  we agree that the current
> >        undefined  meaning  must  be  deprecated  as  there  is   no
> >        interoperability.
> >
> >        (1.1.2.9.4) 2445 - New CLASS  There seems to be a strong desire
> >        to keep this.  See "Access Control" below.
> >
> >        (1.1.3) 2445 - New VTODO draft
> >
> >        (1.1.4) 2445 - New VJOURNAL draft
> >
> >        (1.1.5) 2445 - NEW VALARM draft  Need to define  when  to  send
> >        them.  Need an exhaustive discussion.
> >
> >        (1.1.6) 2445  - How  to  handle  time  zones in CUAs.  I have a
> >        proposal on new time zone format for CUAs  to  share  common
> >        time zone data.  Need more feedback.
> >
> >
> >
> >        (2) 2446 - (iTIP) Changes and fixes.
> >
> >        (2.1) 2446 - Simplify updates - settle on one way
> >
> >
> >
> >        (3) 2447 - (iMIP) Changes and fixes.
> >
> >        (3.1) 2447 - Specify minimum  MIME support needed
> >
> >
> >        (4)  New - Access Control
> >
> >        The  access  control  over  iMIP  is not the same as access
> >        control needed for client/server transport of objects.  Need
> >        to define and document.
> >
> > --
> >
> > Doug Royer                     |   http://INET-Consulting.com
> > -------------------------------|-----------------------------
> > [e-mail]                 | Office: [phone]
> > http://Royer.com/People/Doug   | Fax:    [phone]
> >                                | Cell:   [phone]
> >
> >               We Do Standards - You Need Standards
> >
> >
> >
>_______________________________________________
>Ietf-calsify mailing list
>[e-mail]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8E1bipo031438 for <[e-mail]>; Mon, 13 Sep 2004 18:37:44 -0700
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);  Mon, 13 Sep 2004 18:37:43 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 13 Sep 2004 18:37:44 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Sep 2004 18:37:43 -0700
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Sep 2004 18:37:46 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?
Date: Mon, 13 Sep 2004 18:37:43 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?
thread-index: AcSZ+IlYfvQVQOdFSJa2hAiA95VCtwAAHJEg
From: "Cameron Stillion" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 14 Sep 2004 01:37:46.0716 (UTC) FILETIME=[6FF191C0:01C499FB]
X-Scanned-By: MIMEDefang 2.39
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i8E1bipo031438
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 01:37:45 -0000

I agree with the question...

> The question we need to ask is:
> 
>    Do we want to be able to transfer 'sync' an entire calendar in one
pass?
>
> If yes, then we have to allow multiple BEGIN/END per transfer.

But I disagree with your reasoning.

Transferring an entire calendar in one pass - does not seem to require
more than one METHOD. If I am publishing an entire calendar, then I have
one VCALENDAR with METHOD=PUBLISH.  If I am sending a request for you to
attend a whole calendar's worth of meetings, then I presume I have one
VCALENDAR with METHOD=REQUEST.  

The scenario you describe above seems to never need more than one
method.  Only when batching multiple REQUEST/UPDATE/PUBLISH do we get
into needing multiple VCALENDARS. But this is not processing a calendar
so much as processing multiple transactions to a calendar.

Perhaps I'm looking at it more from a client transport interop
perspective again... But if so, then help me understand the real
scenario that leads us to this need.


Cameron


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Doug Royer
Sent: Monday, September 13, 2004 6:15 PM
To: [e-mail]
Subject: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?


I think its a new issue.

When transferring only booked entries one begin/end works.

However METHOD is global to BEGIN/END VCALENDAR and you can not have a
single BEGIN/END VCALENDAR that contains more than one METHOD value
type.

So, if you are transporting more than one METHOD, you MUST use multiple
BEGIN/END VCALENDAR objects.

iMIP  enforces only one METHOD per MIME object.
So you can not transfer an entire calendar in one iMIP MIME object
anyway.

CAP has a VCALSTORE component that can encapsulate many VCALENDAR
objects as a way to solve that problem.

Do we want to create a wrapper object (VCALSTORE?) so that we can
transfer multiple METHOD VCALENDAR objects?

If not, then implementations that do not accept multiple BEGIN/END
vcalendar objects can not transfer any iTIP object that might be in a
calendar in a single transfer.

Not an answer - just some info...

The question we need to ask is:

    Do we want to be able to transfer 'sync' an entire calendar in one
pass?

If yes, then we have to allow multiple BEGIN/END per transfer.

I think the answer is yes.

Oren Sreebny wrote:

>Does 1.1.1 include this issue?
>
>----------------------
>
>2445 says that "The Calendaring and Scheduling Core Object is a 
>collection of calendaring and scheduling information.
>Typically, this information will consist of a single iCalendar object.
>However, multiple iCalendar objects can be sequentially grouped
together."
>
>But implementations don't all support multiple VCALENDAR blocks - for 
>instance, in Oracle Cal when you export iCalendar data it surrounds  
>each VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither 
>Apple's iCal nor Outlook will accept that as an import format - they 
>want all the VEVENTs grouped within a single VCALENDAR block.
>
>Or is this a new issue?
>  
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards





X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8E1Yopp031326 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 18:34:50 -0700
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12]) by inet-mail1.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i8E1HDAU025317 for <[e-mail]>; Mon, 13 Sep 2004 18:36:53 -0700 (PDT)
Received: from rgmgw3.us.oracle.com (localhost [127.0.0.1]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i8E0q1vY020715 for <[e-mail]>; Mon, 13 Sep 2004 18:52:01 -0600
Received: from [192.168.0.2] (emea-vpn-gw2-uk-gateway.vpn.oracle.com [141.144.128.1]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i8E0q0P5020665 for <[e-mail]>; Mon, 13 Sep 2004 18:52:00 -0600
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 20:51:58 -0400
From: Keith MacDonald <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] List issues so far.
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 01:34:51 -0000

We consider this to be a bug with our iCal implementation in a few of 
our client products and will almost certainly be changed.

-km

Oren Sreebny wrote:
> Does 1.1.1 include this issue?
> 
> ----------------------
> 
> 2445 says that "The Calendaring and Scheduling Core
> Object is a collection of calendaring and scheduling information.
> Typically, this information will consist of a single iCalendar object.
> However, multiple iCalendar objects can be sequentially grouped together."
> 
> But implementations don't all support multiple VCALENDAR blocks - for
> instance, in Oracle Cal when you export iCalendar data it surrounds  each
> VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither Apple's iCal
> nor Outlook will accept that as an import format - they want all the
> VEVENTs grouped within a single VCALENDAR block.
> 
> Or is this a new issue?
> 
> - Oren
> 
> 
> On Mon, 13 Sep 2004, Doug Royer wrote:
> 
> 
>>       List if ideas (in random order) on this list.
>>
>>       (1). 2445 - (iCAL) Changes and fixes.
>>
>>       (1.1) 2445 - Split into separate drafts
>>
>>       This allows for separation of topics and allows each to make
>>       it or not to standard.
>>
>>       (1.1.1) 2445 - Basic which includes VEVENT
>>
>>       (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.
>>
>>       (1.1.2) 2445 - Simplify recursions.  I think we are  saying  we
>>       want to do this, we need a more specific proposal.
>>
>>       (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
>>       are saying  want  to  do  this,  we  need  a  more  specific
>>       proposal.
>>
>>       (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
>>       that allows this.  Deprecate it?
>>
>>       (1.1.2.3) 2445 - No more than one RRULE per component?  I think
>>       we  are  saying  we want to do this, we need a more specific
>>       proposal.
>>
>>       (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
>>       want  to  do this, we need a more specific proposal and will
>>       involve time zone data being evaluated at CUA only.
>>
>>       (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
>>       want to do this.
>>
>>       (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
>>       values. (FBTYPE).  Do we need more discussion?
>>
>>       (1.1.2.7) 2445 - ALTREP  I do not think  we  have  proven  that
>>       this is a compatibility issue as a CUA can or can not use it
>>       and it does not effect the data or flow of data.  CUAs  that
>>       can  not  display  the  data  ignore it anyway.  Having this
>>       property does not break CUAs that do not use it.   How  many
>>       use this?
>>
>>       (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
>>       this is a compatibility issue as a CUA can or can not use it
>>       and it does not effect the data or flow of data.  Thin CUA's
>>       can not use it anyway and ignore it.  Having  this  property
>>       does  not break CUAs that do not use it.  How many use this?
>>
>>       This eliminates the need to send VTIMEZONE.
>>
>>       (1.1.2.9) 2445 - Deprecate properties
>>
>>       (1.1.2.9.1) 2445 - GEO  I think we are saying NO, however  only
>>       GREGORIAN in scope at this time.
>>
>>       (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.
>>
>>       (1.1.2.9.3) 2445 - CLASS   I  think  we agree that the current
>>       undefined  meaning  must  be  deprecated  as  there  is   no
>>       interoperability.
>>
>>       (1.1.2.9.4) 2445 - New CLASS  There seems to be a strong desire
>>       to keep this.  See "Access Control" below.
>>
>>       (1.1.3) 2445 - New VTODO draft
>>
>>       (1.1.4) 2445 - New VJOURNAL draft
>>
>>       (1.1.5) 2445 - NEW VALARM draft  Need to define  when  to  send
>>       them.  Need an exhaustive discussion.
>>
>>       (1.1.6) 2445  - How  to  handle  time  zones in CUAs.  I have a
>>       proposal on new time zone format for CUAs  to  share  common
>>       time zone data.  Need more feedback.
>>
>>
>>
>>       (2) 2446 - (iTIP) Changes and fixes.
>>
>>       (2.1) 2446 - Simplify updates - settle on one way
>>
>>
>>
>>       (3) 2447 - (iMIP) Changes and fixes.
>>
>>       (3.1) 2447 - Specify minimum  MIME support needed
>>
>>
>>       (4)  New - Access Control
>>
>>       The  access  control  over  iMIP  is not the same as access
>>       control needed for client/server transport of objects.  Need
>>       to define and document.
>>
>>--
>>
>>Doug Royer                     |   http://INET-Consulting.com
>>-------------------------------|-----------------------------
>>[e-mail]                 | Office: [phone]
>>http://Royer.com/People/Doug   | Fax:    [phone]
>>                               | Cell:   [phone]
>>
>>              We Do Standards - You Need Standards
>>
>>
>>
> 
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--------------------------------------------------------
Software Development Manager, OCS Desktop Calendar Clients
Time management Platform, Server Technologies
Oracle Corp.


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8E1TSpp031096 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 13 Sep 2004 18:29:29 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8E1TKSw025095 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 18:29:21 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 19:29:20 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090504000209020309040503"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 01:29:30 -0000

This is a cryptographically signed message in MIME format.

--------------ms090504000209020309040503
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



So far this is no WG - this is just a mailing list.

The IETF has an ISSUE page/tool , I think that we should use that.

People will need to write drafts, submit them, and get feedback. That
is the process. Until there is a draft, there is nothing do decide.

A simple typo will be noteworthy, but not that relevant as there
will be new drafts written that may take some of the existing text.
A typo list can be used to verify the same mistakes are not taken again.

Another problem is that the compatibly testing has been very limited
so far. A small handful of vendor that could afford to pay the price
to attend is far from an exhaustive compatibility testing.

 I would propose that we (I'll volunteer) to setup some free testing.
Not sure what we need yet.  The results of the commercial testing
have not yet been provided.


Mark Swanson wrote:

>Thanks for the response.
>
>However, I really am wondering what the process is. For example, in the 
>simplest case where we want to fix a 2445 typo and we all agree. Is there a 
>person or group that will maintain _the_ fix list that will be accepted by 
>the IETF. Or is the list simply to be maintained ad-hoc by the people on the 
>mailing list. Or, what... ? I seem to have missed the memo.
>
>Thanks.
>
>  
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms090504000209020309040503
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTE0MDEyOTIwWjAjBgkqhkiG9w0BCQQxFgQU9D4ZXTPAf4+SW/gvPadP
BVk/1hEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAAt8SgxRdf3+J2woOp4pg8rXqoDgCo9bpDUCVACPjhzscN27AVnNC641RJwKcNQ0U
1Bbzz87xkQ1en7el3X8jU/1s7dD6xwDkng9NBS6n3u24m57pLnlW72/8Sbk65wCPZOP+bZMl
DIzY2lSpMMUCTOEzRX4oc1VGTZvmlgJQM9g1sv83UqQ3i5w0Eg2dkFJnLV2QnefavA6pSPno
DF6h+9Eywuk031UkQVzx0W80vjL4WpBsD/bUi96cbNsw2vVBkUGVXelxkyP3oNhi4CQtz3HB
2qkP50QpNuBQhMXKMhONkTn6FdlFZ22f08OUOHzVm/bxEAyxD7tk9HBcikVtwwAAAAAAAA==
--------------ms090504000209020309040503--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [69.44.62.208]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id i8E1GQpo029379 for <[e-mail]>; Mon, 13 Sep 2004 18:16:26 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 311 for <[e-mail]>; Mon, 13 Sep 2004 20:15:56 -0500 (CDT)
From: Mark Swanson <[e-mail]>
Organization: Web Service Solutions, Inc.
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
Date: Mon, 13 Sep 2004 21:16:28 -0400
User-Agent: KMail/1.6.2
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 01:16:26 -0000

Thanks for the response.

However, I really am wondering what the process is. For example, in the 
simplest case where we want to fix a 2445 typo and we all agree. Is there a 
person or group that will maintain _the_ fix list that will be accepted by 
the IETF. Or is the list simply to be maintained ad-hoc by the people on the 
mailing list. Or, what... ? I seem to have missed the memo.

Thanks.

-- 
Free SyncML-capable replacement for Exchange and Outlook
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8E1Erpp029268 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 13 Sep 2004 18:14:54 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8E1EfSw024895 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 18:14:43 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 19:14:41 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000201000906030001080200"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 01:14:55 -0000

This is a cryptographically signed message in MIME format.

--------------ms000201000906030001080200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


I think its a new issue.

When transferring only booked entries one begin/end works.

However METHOD is global to BEGIN/END VCALENDAR and
you can not have a single BEGIN/END VCALENDAR that
contains more than one METHOD value type.

So, if you are transporting more than one METHOD,
you MUST use multiple BEGIN/END VCALENDAR objects.

iMIP  enforces only one METHOD per MIME object.
So you can not transfer an entire calendar in
one iMIP MIME object anyway.

CAP has a VCALSTORE component that can encapsulate
many VCALENDAR objects as a way to solve that problem.

Do we want to create a wrapper object (VCALSTORE?) so that
we can transfer multiple METHOD VCALENDAR objects?

If not, then implementations that do not accept multiple BEGIN/END
vcalendar objects can not transfer any iTIP object that might be
in a calendar in a single transfer.

Not an answer - just some info...

The question we need to ask is:

    Do we want to be able to transfer 'sync' an entire calendar in one pass?

If yes, then we have to allow multiple BEGIN/END per transfer.

I think the answer is yes.

Oren Sreebny wrote:

>Does 1.1.1 include this issue?
>
>----------------------
>
>2445 says that "The Calendaring and Scheduling Core
>Object is a collection of calendaring and scheduling information.
>Typically, this information will consist of a single iCalendar object.
>However, multiple iCalendar objects can be sequentially grouped together."
>
>But implementations don't all support multiple VCALENDAR blocks - for
>instance, in Oracle Cal when you export iCalendar data it surrounds  each
>VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither Apple's iCal
>nor Outlook will accept that as an import format - they want all the
>VEVENTs grouped within a single VCALENDAR block.
>
>Or is this a new issue?
>  
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms000201000906030001080200
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTE0MDExNDQxWjAjBgkqhkiG9w0BCQQxFgQUzJ/p8eeTG5NSgz2b3c+Q
xzogr0owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAiyaRFydgdE5pmnMJLS9eZGv6c/SX1GgczGYZv2oU/2uylYCQ/DsifrctlBphA6i2
qOzeGe5S9rXD4CEtSoUFysw5yq0fHdlhOerLljO9wIguL6tD1FdALPOsYG+vokO/weMmJNDy
1YRhg93mi+JmoZ+VeBrLolIURG4xahKR8K0fNf3p1v6iE1qyjhU6ci91TvB/rlTVgXTyZOmW
KDBvR0nRIwWoZvOX2nmboLGffwInYu6hjchJ+Dod27hkMTlWrZOaSmwGp8/areJZxllSE0GC
p8HD6gJ9MHqKZ7zUW4k09iZDKFeIXW4lwaluJMusiwnGcxEfvV4BHpKWRZyADAAAAAAAAA==
--------------ms000201000906030001080200--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8E0empo027747 for <[e-mail]>; Mon, 13 Sep 2004 17:40:48 -0700
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);  Mon, 13 Sep 2004 17:40:48 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 13 Sep 2004 17:40:47 -0700
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Sep 2004 17:40:47 -0700
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Sep 2004 17:40:55 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] List issues so far.
Date: Mon, 13 Sep 2004 17:40:46 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] List issues so far.
thread-index: AcSZ8x2igBm4UgiDRc+nDIltsa7AGwAAB3rw
From: "Cameron Stillion" <[e-mail]>
To: "Oren Sreebny" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 14 Sep 2004 00:40:55.0820 (UTC) FILETIME=[7EE424C0:01C499F3]
X-Scanned-By: MIMEDefang 2.39
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i8E0empo027747
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 00:40:49 -0000

Good Catch Oren... Perhaps it hasn't been mentioned yet.  I heartily
agree that we should remove this "additionally confusing way" to group
calendar events.  Especially since there is no clear statement of what
it means to do so, or why a CUA would want to...

Cameron


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Oren
Sreebny
Sent: Monday, September 13, 2004 5:31 PM
To: [e-mail]
Subject: Re: [Ietf-calsify] List issues so far.

Does 1.1.1 include this issue?

----------------------

2445 says that "The Calendaring and Scheduling Core Object is a
collection of calendaring and scheduling information.
Typically, this information will consist of a single iCalendar object.
However, multiple iCalendar objects can be sequentially grouped
together."

But implementations don't all support multiple VCALENDAR blocks - for
instance, in Oracle Cal when you export iCalendar data it surrounds
each VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither Apple's
iCal nor Outlook will accept that as an import format - they want all
the VEVENTs grouped within a single VCALENDAR block.

Or is this a new issue?

- Oren


On Mon, 13 Sep 2004, Doug Royer wrote:

>
>        List if ideas (in random order) on this list.
>
>        (1). 2445 - (iCAL) Changes and fixes.
>
>        (1.1) 2445 - Split into separate drafts
>
>        This allows for separation of topics and allows each to make
>        it or not to standard.
>
>        (1.1.1) 2445 - Basic which includes VEVENT
>
>        (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.
>
>        (1.1.2) 2445 - Simplify recursions.  I think we are  saying  we
>        want to do this, we need a more specific proposal.
>
>        (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
>        are saying  want  to  do  this,  we  need  a  more  specific
>        proposal.
>
>        (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
>        that allows this.  Deprecate it?
>
>        (1.1.2.3) 2445 - No more than one RRULE per component?  I think
>        we  are  saying  we want to do this, we need a more specific
>        proposal.
>
>        (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
>        want  to  do this, we need a more specific proposal and will
>        involve time zone data being evaluated at CUA only.
>
>        (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
>        want to do this.
>
>        (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
>        values. (FBTYPE).  Do we need more discussion?
>
>        (1.1.2.7) 2445 - ALTREP  I do not think  we  have  proven  that
>        this is a compatibility issue as a CUA can or can not use it
>        and it does not effect the data or flow of data.  CUAs  that
>        can  not  display  the  data  ignore it anyway.  Having this
>        property does not break CUAs that do not use it.   How  many
>        use this?
>
>        (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
>        this is a compatibility issue as a CUA can or can not use it
>        and it does not effect the data or flow of data.  Thin CUA's
>        can not use it anyway and ignore it.  Having  this  property
>        does  not break CUAs that do not use it.  How many use this?
>
>        This eliminates the need to send VTIMEZONE.
>
>        (1.1.2.9) 2445 - Deprecate properties
>
>        (1.1.2.9.1) 2445 - GEO  I think we are saying NO, however  only
>        GREGORIAN in scope at this time.
>
>        (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.
>
>        (1.1.2.9.3) 2445 - CLASS   I  think  we agree that the current
>        undefined  meaning  must  be  deprecated  as  there  is   no
>        interoperability.
>
>        (1.1.2.9.4) 2445 - New CLASS  There seems to be a strong desire
>        to keep this.  See "Access Control" below.
>
>        (1.1.3) 2445 - New VTODO draft
>
>        (1.1.4) 2445 - New VJOURNAL draft
>
>        (1.1.5) 2445 - NEW VALARM draft  Need to define  when  to  send
>        them.  Need an exhaustive discussion.
>
>        (1.1.6) 2445  - How  to  handle  time  zones in CUAs.  I have a
>        proposal on new time zone format for CUAs  to  share  common
>        time zone data.  Need more feedback.
>
>
>
>        (2) 2446 - (iTIP) Changes and fixes.
>
>        (2.1) 2446 - Simplify updates - settle on one way
>
>
>
>        (3) 2447 - (iMIP) Changes and fixes.
>
>        (3.1) 2447 - Specify minimum  MIME support needed
>
>
>        (4)  New - Access Control
>
>        The  access  control  over  iMIP  is not the same as access
>        control needed for client/server transport of objects.  Need
>        to define and document.
>
> --
>
> Doug Royer                     |   http://INET-Consulting.com
> -------------------------------|-----------------------------
> [e-mail]                 | Office: [phone]
> http://Royer.com/People/Doug   | Fax:    [phone]
>                                | Cell:   [phone]
>
>               We Do Standards - You Need Standards
>
>
>
_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8E0VRpp027271 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 17:31:27 -0700
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i8E0VQGd010085 for <[e-mail]>; Mon, 13 Sep 2004 17:31:26 -0700
Received: from [192.168.1.106] (c-24-18-181-17.client.comcast.net [24.18.181.17]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i8E0VPao032372 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Mon, 13 Sep 2004 17:31:26 -0700
Date: Mon, 13 Sep 2004 17:31:26 -0700 (PDT)
From: Oren Sreebny <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: [Ietf-calsify] List issues so far.
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.39
X-Mailman-Approved-At: Mon, 13 Sep 2004 17:37:21 -0700
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 00:31:28 -0000

Does 1.1.1 include this issue?

----------------------

2445 says that "The Calendaring and Scheduling Core
Object is a collection of calendaring and scheduling information.
Typically, this information will consist of a single iCalendar object.
However, multiple iCalendar objects can be sequentially grouped together."

But implementations don't all support multiple VCALENDAR blocks - for
instance, in Oracle Cal when you export iCalendar data it surrounds  each
VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither Apple's iCal
nor Outlook will accept that as an import format - they want all the
VEVENTs grouped within a single VCALENDAR block.

Or is this a new issue?

- Oren


On Mon, 13 Sep 2004, Doug Royer wrote:

>
>        List if ideas (in random order) on this list.
>
>        (1). 2445 - (iCAL) Changes and fixes.
>
>        (1.1) 2445 - Split into separate drafts
>
>        This allows for separation of topics and allows each to make
>        it or not to standard.
>
>        (1.1.1) 2445 - Basic which includes VEVENT
>
>        (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.
>
>        (1.1.2) 2445 - Simplify recursions.  I think we are  saying  we
>        want to do this, we need a more specific proposal.
>
>        (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
>        are saying  want  to  do  this,  we  need  a  more  specific
>        proposal.
>
>        (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
>        that allows this.  Deprecate it?
>
>        (1.1.2.3) 2445 - No more than one RRULE per component?  I think
>        we  are  saying  we want to do this, we need a more specific
>        proposal.
>
>        (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
>        want  to  do this, we need a more specific proposal and will
>        involve time zone data being evaluated at CUA only.
>
>        (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
>        want to do this.
>
>        (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
>        values. (FBTYPE).  Do we need more discussion?
>
>        (1.1.2.7) 2445 - ALTREP  I do not think  we  have  proven  that
>        this is a compatibility issue as a CUA can or can not use it
>        and it does not effect the data or flow of data.  CUAs  that
>        can  not  display  the  data  ignore it anyway.  Having this
>        property does not break CUAs that do not use it.   How  many
>        use this?
>
>        (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
>        this is a compatibility issue as a CUA can or can not use it
>        and it does not effect the data or flow of data.  Thin CUA's
>        can not use it anyway and ignore it.  Having  this  property
>        does  not break CUAs that do not use it.  How many use this?
>
>        This eliminates the need to send VTIMEZONE.
>
>        (1.1.2.9) 2445 - Deprecate properties
>
>        (1.1.2.9.1) 2445 - GEO  I think we are saying NO, however  only
>        GREGORIAN in scope at this time.
>
>        (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.
>
>        (1.1.2.9.3) 2445 - CLASS   I  think  we agree that the current
>        undefined  meaning  must  be  deprecated  as  there  is   no
>        interoperability.
>
>        (1.1.2.9.4) 2445 - New CLASS  There seems to be a strong desire
>        to keep this.  See "Access Control" below.
>
>        (1.1.3) 2445 - New VTODO draft
>
>        (1.1.4) 2445 - New VJOURNAL draft
>
>        (1.1.5) 2445 - NEW VALARM draft  Need to define  when  to  send
>        them.  Need an exhaustive discussion.
>
>        (1.1.6) 2445  - How  to  handle  time  zones in CUAs.  I have a
>        proposal on new time zone format for CUAs  to  share  common
>        time zone data.  Need more feedback.
>
>
>
>        (2) 2446 - (iTIP) Changes and fixes.
>
>        (2.1) 2446 - Simplify updates - settle on one way
>
>
>
>        (3) 2447 - (iMIP) Changes and fixes.
>
>        (3.1) 2447 - Specify minimum  MIME support needed
>
>
>        (4)  New - Access Control
>
>        The  access  control  over  iMIP  is not the same as access
>        control needed for client/server transport of objects.  Need
>        to define and document.
>
> --
>
> Doug Royer                     |   http://INET-Consulting.com
> -------------------------------|-----------------------------
> [e-mail]                 | Office: [phone]
> http://Royer.com/People/Doug   | Fax:    [phone]
>                                | Cell:   [phone]
>
>               We Do Standards - You Need Standards
>
>
>


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8E0KYpp025451 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 13 Sep 2004 17:20:36 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8E0KLSw024233 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 17:20:23 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 18:20:20 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040901020002060407050305"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 00:20:37 -0000

This is a cryptographically signed message in MIME format.

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


So far only Robert seem to think that the method he
proposes is documented, standardized, or compatible with
many others.

He did the same thing on the other mailing list and caused
months of delay. I have found over 40 ical products that
can not use that method. Fortunately this mailing list is
not "how can it be done", its "how do people do it".

And currently the vast majority of products simply
replace the objects during an update keeping the same UID.

I do not think that the issue is stalled. I think
that it is fairly clear - replacing the objects
with an entire updated set with the same UID
works with all vendors (including the one that Roberts
company ships) I can find. Robert does not seem to
dispute this, he simply wants everyone to also do
it the 2nd way - and they do not.


>I would like to know what the process is for moving forward on issues like 
>this. I received a description of this mailing list's purpose but that's 
>about it. If a more detailed description of how conflicts are to be resolved 
>and how decisions are actually going to be made is available please point me 
>to it. (Surely not the same process as the previous ietf-calendar mailing 
>list?)
>
>Thank you.
>
>  
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms040901020002060407050305
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTE0MDAyMDIxWjAjBgkqhkiG9w0BCQQxFgQUapwWn1epAaLdFJn8c41i
WsIEbH8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAWY/aLC94E0LfAW3SD9PILt8zllI7g1tuB7FWLaeJk6760EQeDv1l5zfspZo822d5
/NapbrlQyq5hOkbg/7ZihCUKymJKMC8O0EHUaqjDrk09dLDpPfxNicVG1doX8R+zyLqy44+R
AH5SJDIAlUgt4XJJU9tRfLij9vRPzo3ueNHuKjF+xeRYh5npFWkWMRSNWs1QBnuyYx/fOGdu
x8P1KWuQzu64+JrLacAL2iJb+ITZ1M/On4EuU/IcQfUPP4gu9a1iLjKGVh8mnuPK75I2glAS
/OU+CsEKppdX05ItA1IYDZ2LjV4V50/23U7kA+BFSo9F2uyI2tRr01Nyt8HWzAAAAAAAAA==
--------------ms040901020002060407050305--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [69.44.62.208]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id i8E08tpo024028 for <[e-mail]>; Mon, 13 Sep 2004 17:08:56 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 27 for <[e-mail]>; Mon, 13 Sep 2004 19:08:24 -0500 (CDT)
From: Mark Swanson <[e-mail]>
Organization: Web Service Solutions, Inc.
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
Date: Mon, 13 Sep 2004 20:08:56 -0400
User-Agent: KMail/1.6.2
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 00:08:56 -0000

On September 13, 2004 6:42 pm, Doug Royer wrote:
> At his point I am going to consider your posts as trolling.

I would like to know what the process is for moving forward on issues like 
this. I received a description of this mailing list's purpose but that's 
about it. If a more detailed description of how conflicts are to be resolved 
and how decisions are actually going to be made is available please point me 
to it. (Surely not the same process as the previous ietf-calendar mailing 
list?)

Thank you.

-- 
Free SyncML-capable replacement for Exchange and Outlook
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DNIbpp018158 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 13 Sep 2004 16:18:39 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8DNIQSw023368 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 16:18:28 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 17:18:25 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030900010301080607050004"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] List issues so far.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 23:18:42 -0000

This is a cryptographically signed message in MIME format.

--------------ms030900010301080607050004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


       List if ideas (in random order) on this list.

       (1). 2445 - (iCAL) Changes and fixes.

       (1.1) 2445 - Split into separate drafts

       This allows for separation of topics and allows each to make
       it or not to standard.

       (1.1.1) 2445 - Basic which includes VEVENT

       (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.

       (1.1.2) 2445 - Simplify recursions.  I think we are  saying  we
       want to do this, we need a more specific proposal.

       (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
       are saying  want  to  do  this,  we  need  a  more  specific
       proposal.

       (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
       that allows this.  Deprecate it?

       (1.1.2.3) 2445 - No more than one RRULE per component?  I think
       we  are  saying  we want to do this, we need a more specific
       proposal.

       (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
       want  to  do this, we need a more specific proposal and will
       involve time zone data being evaluated at CUA only.

       (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
       want to do this.

       (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
       values. (FBTYPE).  Do we need more discussion?

       (1.1.2.7) 2445 - ALTREP  I do not think  we  have  proven  that
       this is a compatibility issue as a CUA can or can not use it
       and it does not effect the data or flow of data.  CUAs  that
       can  not  display  the  data  ignore it anyway.  Having this
       property does not break CUAs that do not use it.   How  many
       use this?

       (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
       this is a compatibility issue as a CUA can or can not use it
       and it does not effect the data or flow of data.  Thin CUA's
       can not use it anyway and ignore it.  Having  this  property
       does  not break CUAs that do not use it.  How many use this?

       This eliminates the need to send VTIMEZONE.

       (1.1.2.9) 2445 - Deprecate properties

       (1.1.2.9.1) 2445 - GEO  I think we are saying NO, however  only
       GREGORIAN in scope at this time.

       (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.

       (1.1.2.9.3) 2445 - CLASS   I  think  we agree that the current
       undefined  meaning  must  be  deprecated  as  there  is   no
       interoperability.

       (1.1.2.9.4) 2445 - New CLASS  There seems to be a strong desire
       to keep this.  See "Access Control" below.

       (1.1.3) 2445 - New VTODO draft

       (1.1.4) 2445 - New VJOURNAL draft

       (1.1.5) 2445 - NEW VALARM draft  Need to define  when  to  send
       them.  Need an exhaustive discussion.

       (1.1.6) 2445  - How  to  handle  time  zones in CUAs.  I have a
       proposal on new time zone format for CUAs  to  share  common
       time zone data.  Need more feedback.



       (2) 2446 - (iTIP) Changes and fixes.

       (2.1) 2446 - Simplify updates - settle on one way



       (3) 2447 - (iMIP) Changes and fixes.

       (3.1) 2447 - Specify minimum  MIME support needed


       (4)  New - Access Control

       The  access  control  over  iMIP  is not the same as access
       control needed for client/server transport of objects.  Need
       to define and document.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms030900010301080607050004
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMjMxODI1WjAjBgkqhkiG9w0BCQQxFgQU5oAeTBJ1GwPEfiVw72Yb
xc7C0IQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAdT+lEBl4K4TE/7hFLgsmQqFguODWYURrhupek2qkZQDrrsNbT/U0Mo/HMnMLtyb8
WHA5Po0Mk4CE5tOE1pSK2F6N7B3VUbmjwAgsgIER0TUQWoETBr5fqMsm0CmhoI1I2Xx+WaGF
qX6JYNzzEBNI9GtLIurH4QzPk7pa+tDDbkDBRAnJVHqUggmUKdOxXesBulFipluAgm9iNCiE
WPxGd3HWEfaEFuRzxZoTALWQl/u0P3U3pdpTN3fM9xnO/ToR812K15M/KkEPZ2bYNK9WT4n9
yAcn/BelnJaiVBFCxWoZPR2sHOKLNbGjj9KJax2fA6EKd+YYsNuz6afvcHqlWAAAAAAAAA==
--------------ms030900010301080607050004--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DMh0pp011494 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 13 Sep 2004 15:43:02 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8DMgnSw022845 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 15:42:52 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 16:42:49 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000401070600010609030604"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 22:43:03 -0000

This is a cryptographically signed message in MIME format.

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



At his point I am going to consider your posts as trolling.

Does any one (else) have any input on this topic?

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms000401070600010609030604
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMjI0MjQ5WjAjBgkqhkiG9w0BCQQxFgQUhYyAF2TCKD9D6N9t2BkC
G1b7CDowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEANi1MjJ/pneMopJusStAwNqRDIdhncrVsLXgXZmvrzOH5rKbIdSq6ZQqAQtAdR5Wc
mv6OJ0C/9TOAmZOKHyrMPURjiWpAHNVdn0SWJLE9kSu5QYWuf6Y/z619gHy31cD2g1aULlvK
zI81XLHcH8UOja1ZuKu+nNfRncz44cwhIaUoGvPjGpfJ1sQIPShxXUqjrYmt9VEti4Fs1X97
C84vE5rIDUQ6XWW2mOf6TYGB9YKt+fjZnyJan2HU3UoVvr2G5RPdjc2Pp576HYy9N/BLwFdb
UX5g/QcmyxODVnYtOp/yOaUx93csT1iveOZaUa5pJEoFtmJH0Ny9+cFCl2x7uAAAAAAAAA==
--------------ms000401070600010609030604--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DMHfpo010327 for <[e-mail]>; Mon, 13 Sep 2004 15:17:42 -0700
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 13 Sep 2004 18:18:07 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 09/13/2004 06:14:47 PM
Content-Type: multipart/mixed; boundary="=_mixed 007A53DB85256F0E_="
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 22:17:43 -0000

This is a multi-part message in MIME format...

--=_mixed 007A53DB85256F0E_=
Content-Type: multipart/alternative; boundary="----------=_1095113862-978-323"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095113862-978-323
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

because you said 

>I propose we deprecate that method of updates.

>Just send the new objects as a replacement set.

>Very few implementations support that model of changes. No real 
>interoperablity.
>Almost everyone sends entire replacement objects.

>The 'OR' is part of the problem. More than one way to do the
>same thing is causing some of the incompatibility problems.


Withoug RIDs, you can not make individule changes to instances.




Doug Royer <[e-mail]> 
Sent by: [e-mail]
09/13/2004 05:56 PM
Please respond to
[e-mail]


To
[e-mail]
cc

Subject
Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed








[e-mail] wrote:

>by sending a NEW rule you are telling me everything I have is invalid. 
>Throw it away.
>Most of the time what we really want to do is just change a single 
>instance or maybe move the entire meeting set.  In either of these cases 
>we probably do not want to throw out any description changes that already 

>exist on individual instances. 
> 
>
Then why did you say:

>>Thus you should send a cancel and sent the new RULE with a new UID.
>>
>> 
>>
Which throws away the description among ALL other things ?

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


------------=_1095113862-978-323--

--=_mixed 007A53DB85256F0E_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
AQAAoIINcDCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZI
hvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4
MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rI
SsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+
MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG
+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY
UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5Jz
dC6JOzUTcudAMZrTssSr51a+i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBB
MPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQwHhcNMDQwOTAzMDAwMDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91
ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMWHYQKNX06SDOZPZvQOVD5lgC
2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4IaamL0bbVrINBtK
mW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo
0Y6uq+kkkPqYd+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQz
FWwe1UaHKYPb8d8xO6qGJNisRNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IH
nwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJBgNVHRMEAjAAMIGsBgNVHSAE
gaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM26zHybGdD0C7c
Q+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J3
8rgwggUBMIIEaqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEB
BAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAw
MFoXDTA1MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B
CQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAzFh2ECjV9OkgzmT2b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUE
k1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSpluabeSeXZhFTAZSp7mqR8kZM55
LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ+SIZOInZLPfU
iloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETS
N4vU/WT1Pv+IAvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IB
HDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT
aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcE
BhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp
4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPrGpYuUwn62iMbUSaGXYFlg0Am
2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOSzi6mbsF7ZSIc
2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wCQYF
Kw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMjE1NjMzWjAjBgkqhkiG9w0BCQQxFgQUwFBq9qnE
+r7cuP29Hj64GC50ZzAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90
IFZhbGlkYXRlZAIQV2Y2bnhVsEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsx
geSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg
U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wDQYJKoZIhvcNAQEBBQAEggEAX4HFWKgZjOcHf/2Rl24OdJXX+YgE
XsfgWR+U7J/GQoER8pvHmooK84SIAZjXSVED9A5ViAYrJTZVlnDWifQYFfwU
8K6xHYCdz6M3pw2CixoJVDvD25qho9IofvmxWWIS3h9tBM+wec4mIODvnQwz
W2w+f8f17c5wBnIGKV1SPQsKC4wjdZBM5wScTqHDMSeVktb7EWQYzcU2N/qo
m4DDcQ7GTMlkqi0m5/lJVfszVc4JWput3t3nm9CBI34nTJpkzhioZ2Lfcvgv
LLx9bl8Dn2hpkG57GDQVjx8qtyI/cyRvNihwmnkGEQZzhPWg+0OmReL2tEaO
pfxmUXtJwzx+lQAAAAAAAA==

--=_mixed 007A53DB85256F0E_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DLugpp009210 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 13 Sep 2004 14:56:44 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8DLuXSw022008 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 14:56:35 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 15:56:33 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000207030804010500060502"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 21:56:45 -0000

This is a cryptographically signed message in MIME format.

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



[e-mail] wrote:

>by sending a NEW rule you are telling me everything I have is invalid. 
>Throw it away.
>Most of the time what we really want to do is just change a single 
>instance or maybe move the entire meeting set.  In either of these cases 
>we probably do not want to throw out any description changes that already 
>exist on individual instances. 
>  
>
Then why did you say:

>>Thus you should send a cancel and sent the new RULE with a new UID.
>>
>>    
>>
Which throws away the description among ALL other things ?

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms000207030804010500060502
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMjE1NjMzWjAjBgkqhkiG9w0BCQQxFgQUwFBq9qnE+r7cuP29Hj64
GC50ZzAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAX4HFWKgZjOcHf/2Rl24OdJXX+YgEXsfgWR+U7J/GQoER8pvHmooK84SIAZjXSVED
9A5ViAYrJTZVlnDWifQYFfwU8K6xHYCdz6M3pw2CixoJVDvD25qho9IofvmxWWIS3h9tBM+w
ec4mIODvnQwzW2w+f8f17c5wBnIGKV1SPQsKC4wjdZBM5wScTqHDMSeVktb7EWQYzcU2N/qo
m4DDcQ7GTMlkqi0m5/lJVfszVc4JWput3t3nm9CBI34nTJpkzhioZ2LfcvgvLLx9bl8Dn2hp
kG57GDQVjx8qtyI/cyRvNihwmnkGEQZzhPWg+0OmReL2tEaOpfxmUXtJwzx+lQAAAAAAAA==
--------------ms000207030804010500060502--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DLucpo009204 for <[e-mail]>; Mon, 13 Sep 2004 14:56:38 -0700
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 13 Sep 2004 17:57:03 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 09/13/2004 05:53:43 PM
Content-Type: multipart/mixed; boundary="=_mixed 007865FA85256F0E_="
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 21:56:39 -0000

This is a multi-part message in MIME format...

--=_mixed 007865FA85256F0E_=
Content-Type: multipart/alternative; boundary="----------=_1095112598-978-244"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095112598-978-244
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

It is well documented and discussed last year. 
You mean your product does not use it.




Doug Royer <[e-mail]> 
Sent by: [e-mail]
09/13/2004 05:43 PM
Please respond to
[e-mail]


To
[e-mail]
cc

Subject
Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed








[e-mail] wrote:

>You can make changes using the standard RID method.
> 
>
First - that methid is not documented in 244[567], and it is not 
'standard'.

Second - Almost ALL implementation do not do it that way.

So why should we bother considering it?

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


------------=_1095112598-978-244--

--=_mixed 007865FA85256F0E_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
AQAAoIINcDCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZI
hvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4
MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rI
SsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+
MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG
+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY
UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5Jz
dC6JOzUTcudAMZrTssSr51a+i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBB
MPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQwHhcNMDQwOTAzMDAwMDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91
ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMWHYQKNX06SDOZPZvQOVD5lgC
2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4IaamL0bbVrINBtK
mW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo
0Y6uq+kkkPqYd+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQz
FWwe1UaHKYPb8d8xO6qGJNisRNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IH
nwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJBgNVHRMEAjAAMIGsBgNVHSAE
gaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM26zHybGdD0C7c
Q+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J3
8rgwggUBMIIEaqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEB
BAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAw
MFoXDTA1MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B
CQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAzFh2ECjV9OkgzmT2b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUE
k1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSpluabeSeXZhFTAZSp7mqR8kZM55
LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ+SIZOInZLPfU
iloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETS
N4vU/WT1Pv+IAvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IB
HDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT
aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcE
BhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp
4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPrGpYuUwn62iMbUSaGXYFlg0Am
2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOSzi6mbsF7ZSIc
2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wCQYF
Kw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMjE0MzAyWjAjBgkqhkiG9w0BCQQxFgQUNtV2eVk/
jwLWfz2QcuD2fXSXeI0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90
IFZhbGlkYXRlZAIQV2Y2bnhVsEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsx
geSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg
U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wDQYJKoZIhvcNAQEBBQAEggEAn77EXLrAE4DD6W91XVj1KsNvhamw
hS0RhlWe9ebFEJOKQzPGXOzIXh7qDGqDl9L9KParXu72bkKABgynnM/4vuyi
JuJmBni76LrXguC+tfbXsmSXB4qznF6evLNwSYynqAiQoEb+m8iQ8u/rQfCL
Ep7JWhaHk0BxpMsFYf/Wa2C4zUuR3iBGZtRzqojWxTpfShMPfm0Gtq5lRG6d
FVlGMYt9ooyD1/yt67mO1Qtq4GzFlqtqZlyFm3kgVr8vwXinMF9/KcevBTeM
J+9V4uFpFBU6sBikORE+ixsiITro7BNnge1EB9JBRzXiYBBZdqPWj+3IgKB4
pSKPvLTXSh8MZgAAAAAAAA==

--=_mixed 007865FA85256F0E_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DLjspo008530 for <[e-mail]>; Mon, 13 Sep 2004 14:45:54 -0700
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 13 Sep 2004 17:46:18 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 09/13/2004 05:42:59 PM
Content-Type: multipart/mixed; boundary="=_mixed 007769EC85256F0E_="
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 21:45:54 -0000

This is a multi-part message in MIME format...

--=_mixed 007769EC85256F0E_=
Content-Type: multipart/alternative; boundary="----------=_1095111954-978-213"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095111954-978-213
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

by sending a NEW rule you are telling me everything I have is invalid. 
Throw it away.
Most of the time what we really want to do is just change a single 
instance or maybe move the entire meeting set.  In either of these cases 
we probably do not want to throw out any description changes that already 
exist on individual instances. 



Doug Royer <[e-mail]> 
Sent by: [e-mail]
09/13/2004 05:14 PM
Please respond to
[e-mail]


To
[e-mail]
cc

Subject
Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed







That make no sense at all. You effetely have declared
that no one can ever make changes.

I know of no product that does this, why would we want to
change to this method you propose? The idea of this mailing
list is to simplify and make compatible objects. This would make
a huge percentage of products incompatible with the current object
methods.

You would force two sets of objects - the cancel objets followed
by exactly what I said - a replacement set - except
the end CU/CUA would not know they are a replacement set.
What is the advantage over just sending a replacement set?


[e-mail] wrote:

>This is equivalent to sending a cancel on all the events and then 
>resetting the RID values with new dates.
>Thus you should send a cancel and sent the new RULE with a new UID.
> 
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ietf-calsify mailing list
>[e-mail]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


------------=_1095111954-978-213--

--=_mixed 007769EC85256F0E_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
AQAAoIINcDCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZI
hvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4
MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rI
SsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+
MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG
+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY
UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5Jz
dC6JOzUTcudAMZrTssSr51a+i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBB
MPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQwHhcNMDQwOTAzMDAwMDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91
ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMWHYQKNX06SDOZPZvQOVD5lgC
2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4IaamL0bbVrINBtK
mW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo
0Y6uq+kkkPqYd+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQz
FWwe1UaHKYPb8d8xO6qGJNisRNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IH
nwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJBgNVHRMEAjAAMIGsBgNVHSAE
gaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM26zHybGdD0C7c
Q+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J3
8rgwggUBMIIEaqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEB
BAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAw
MFoXDTA1MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B
CQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAzFh2ECjV9OkgzmT2b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUE
k1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSpluabeSeXZhFTAZSp7mqR8kZM55
LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ+SIZOInZLPfU
iloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETS
N4vU/WT1Pv+IAvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IB
HDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT
aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcE
BhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp
4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPrGpYuUwn62iMbUSaGXYFlg0Am
2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOSzi6mbsF7ZSIc
2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wCQYF
Kw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMjExNDIxWjAjBgkqhkiG9w0BCQQxFgQU4BWV0EXA
imRE9xbNAYHWYa3xy1IwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90
IFZhbGlkYXRlZAIQV2Y2bnhVsEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsx
geSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg
U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wDQYJKoZIhvcNAQEBBQAEggEAb3qVihu0xf6yGsAfOd27exrG72VW
iSZI3fycHc6OwARyDnIXpToYJto8Ao2IcFuntQMcp4YD6Xe1jK/vji/mHn6k
9IEpT/ihFfIWqXUrYU95h2eaQR5fWD6sfEYwf7hj+hOqpKaCGqIvtM/u9vzO
yVkOXAacpSK64QVEGqOgQ8hvgvoscGEYZqU5EDSU0vNKKhBctH+ba41T8Kiu
bgd++r8/AO/Vu37zy+fQx0yavruFdWRMTcPqAVexFnlqmDiriPaCjQ4fQU6P
LcZktGxW8JykKu/vAXFndRtCfmj+SOc3g1fLgEkHVzWHukgBS3X0CZVe/c9+
s4QhgYe58OjvPAAAAAAAAA==

--=_mixed 007769EC85256F0E_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DLhBpp008437 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 13 Sep 2004 14:43:12 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8DLh3Sw021830 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 14:43:04 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 15:43:02 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090902010104070506060508"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 21:43:13 -0000

This is a cryptographically signed message in MIME format.

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



[e-mail] wrote:

>You can make changes using the standard RID method.
>  
>
First - that methid is not documented in 244[567], and it is not 'standard'.

Second - Almost ALL implementation do not do it that way.

So why should we bother considering it?

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms090902010104070506060508
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMjE0MzAyWjAjBgkqhkiG9w0BCQQxFgQUNtV2eVk/jwLWfz2QcuD2
fXSXeI0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAn77EXLrAE4DD6W91XVj1KsNvhamwhS0RhlWe9ebFEJOKQzPGXOzIXh7qDGqDl9L9
KParXu72bkKABgynnM/4vuyiJuJmBni76LrXguC+tfbXsmSXB4qznF6evLNwSYynqAiQoEb+
m8iQ8u/rQfCLEp7JWhaHk0BxpMsFYf/Wa2C4zUuR3iBGZtRzqojWxTpfShMPfm0Gtq5lRG6d
FVlGMYt9ooyD1/yt67mO1Qtq4GzFlqtqZlyFm3kgVr8vwXinMF9/KcevBTeMJ+9V4uFpFBU6
sBikORE+ixsiITro7BNnge1EB9JBRzXiYBBZdqPWj+3IgKB4pSKPvLTXSh8MZgAAAAAAAA==
--------------ms090902010104070506060508--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DLX6po008053 for <[e-mail]>; Mon, 13 Sep 2004 14:33:07 -0700
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 13 Sep 2004 17:33:30 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 09/13/2004 05:30:11 PM
Content-Type: multipart/mixed; boundary="=_mixed 00763DDF85256F0E_="
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 21:33:07 -0000

This is a multi-part message in MIME format...

--=_mixed 00763DDF85256F0E_=
Content-Type: multipart/alternative; boundary="----------=_1095111187-978-170"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095111187-978-170
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

You can make changes using the standard RID method.






Doug Royer <[e-mail]> 
Sent by: [e-mail]
09/13/2004 05:14 PM
Please respond to
[e-mail]


To
[e-mail]
cc

Subject
Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed







That make no sense at all. You effetely have declared
that no one can ever make changes.

I know of no product that does this, why would we want to
change to this method you propose? The idea of this mailing
list is to simplify and make compatible objects. This would make
a huge percentage of products incompatible with the current object
methods.

You would force two sets of objects - the cancel objets followed
by exactly what I said - a replacement set - except
the end CU/CUA would not know they are a replacement set.
What is the advantage over just sending a replacement set?


[e-mail] wrote:

>This is equivalent to sending a cancel on all the events and then 
>resetting the RID values with new dates.
>Thus you should send a cancel and sent the new RULE with a new UID.
> 
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ietf-calsify mailing list
>[e-mail]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


------------=_1095111187-978-170--

--=_mixed 00763DDF85256F0E_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
AQAAoIINcDCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZI
hvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4
MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rI
SsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+
MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG
+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY
UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5Jz
dC6JOzUTcudAMZrTssSr51a+i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBB
MPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQwHhcNMDQwOTAzMDAwMDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91
ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMWHYQKNX06SDOZPZvQOVD5lgC
2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4IaamL0bbVrINBtK
mW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo
0Y6uq+kkkPqYd+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQz
FWwe1UaHKYPb8d8xO6qGJNisRNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IH
nwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJBgNVHRMEAjAAMIGsBgNVHSAE
gaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM26zHybGdD0C7c
Q+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J3
8rgwggUBMIIEaqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEB
BAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAw
MFoXDTA1MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B
CQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAzFh2ECjV9OkgzmT2b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUE
k1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSpluabeSeXZhFTAZSp7mqR8kZM55
LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ+SIZOInZLPfU
iloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETS
N4vU/WT1Pv+IAvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IB
HDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT
aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcE
BhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp
4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPrGpYuUwn62iMbUSaGXYFlg0Am
2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOSzi6mbsF7ZSIc
2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wCQYF
Kw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMjExNDIxWjAjBgkqhkiG9w0BCQQxFgQU4BWV0EXA
imRE9xbNAYHWYa3xy1IwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90
IFZhbGlkYXRlZAIQV2Y2bnhVsEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsx
geSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg
U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wDQYJKoZIhvcNAQEBBQAEggEAb3qVihu0xf6yGsAfOd27exrG72VW
iSZI3fycHc6OwARyDnIXpToYJto8Ao2IcFuntQMcp4YD6Xe1jK/vji/mHn6k
9IEpT/ihFfIWqXUrYU95h2eaQR5fWD6sfEYwf7hj+hOqpKaCGqIvtM/u9vzO
yVkOXAacpSK64QVEGqOgQ8hvgvoscGEYZqU5EDSU0vNKKhBctH+ba41T8Kiu
bgd++r8/AO/Vu37zy+fQx0yavruFdWRMTcPqAVexFnlqmDiriPaCjQ4fQU6P
LcZktGxW8JykKu/vAXFndRtCfmj+SOc3g1fLgEkHVzWHukgBS3X0CZVe/c9+
s4QhgYe58OjvPAAAAAAAAA==

--=_mixed 00763DDF85256F0E_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DLEWpp007004 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 13 Sep 2004 14:14:34 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8DLELSw021487 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 14:14:23 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 15:14:21 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090909030406060503030009"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 21:14:35 -0000

This is a cryptographically signed message in MIME format.

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


That make no sense at all. You effetely have declared
that no one can ever make changes.

I know of no product that does this, why would we want to
change to this method you propose? The idea of this mailing
list is to simplify and make compatible objects. This would make
a huge percentage of products incompatible with the current object
methods.

You would force two sets of objects - the cancel objets followed
by exactly what I said - a replacement set - except
the end CU/CUA would not know they are a replacement set.
What is the advantage over just sending a replacement set?


[e-mail] wrote:

>This is equivalent to sending a cancel on all the events and then 
>resetting the RID values with new dates.
>Thus you should send a cancel and sent the new RULE with a new UID.
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ietf-calsify mailing list
>[e-mail]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>  
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms090909030406060503030009
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMjExNDIxWjAjBgkqhkiG9w0BCQQxFgQU4BWV0EXAimRE9xbNAYHW
Ya3xy1IwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAb3qVihu0xf6yGsAfOd27exrG72VWiSZI3fycHc6OwARyDnIXpToYJto8Ao2IcFun
tQMcp4YD6Xe1jK/vji/mHn6k9IEpT/ihFfIWqXUrYU95h2eaQR5fWD6sfEYwf7hj+hOqpKaC
GqIvtM/u9vzOyVkOXAacpSK64QVEGqOgQ8hvgvoscGEYZqU5EDSU0vNKKhBctH+ba41T8Kiu
bgd++r8/AO/Vu37zy+fQx0yavruFdWRMTcPqAVexFnlqmDiriPaCjQ4fQU6PLcZktGxW8Jyk
Ku/vAXFndRtCfmj+SOc3g1fLgEkHVzWHukgBS3X0CZVe/c9+s4QhgYe58OjvPAAAAAAAAA==
--------------ms090909030406060503030009--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DKEYpo002904 for <[e-mail]>; Mon, 13 Sep 2004 13:14:34 -0700
To: [e-mail]
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 13 Sep 2004 16:14:09 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 09/13/2004 04:11:39 PM, Serialize complete at 09/13/2004 04:11:39 PM
Content-Type: multipart/alternative; boundary="=_alternative 006F0B0985256F0E_="
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] sending new RRULE/RDATES should not be allowed 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 20:14:35 -0000

This is a multi-part message in MIME format...

--=_alternative 006F0B0985256F0E_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

This is equivalent to sending a cancel on all the events and then 
resetting the RID values with new dates.
Thus you should send a cancel and sent the new RULE with a new UID.
--=_alternative 006F0B0985256F0E_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DK6ppo002497 for <[e-mail]>; Mon, 13 Sep 2004 13:06:51 -0700
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] Changes by RID
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 13 Sep 2004 16:07:17 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 09/13/2004 04:03:56 PM
Content-Type: multipart/mixed; boundary="=_mixed 006E590485256F0E_="
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 20:06:52 -0000

This is a multi-part message in MIME format...

--=_mixed 006E590485256F0E_=
Content-Type: multipart/alternative;
	boundary="----------=_1095106011-26400-115"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095106011-26400-115
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

I disagree.  Most implimentations allow reschedule/updates of instances 
using the RID values.




Doug Royer <[e-mail]> 
Sent by: [e-mail]
09/13/2004 03:58 PM
Please respond to
[e-mail]


To
[e-mail]
cc

Subject
[Ietf-calsify] Changes by RID








[e-mail] wrote:

>Or you just send update using UID/SEQ/DTSTAMP and RID.  The RID is the 
>instance you want to change.
> 
>

I propose we deprecate that method of updates.

Just send the new objects as a replacement set.

Very few implementations support that model of changes. No real 
interoperablity.
Almost everyone sends entire replacement objects.

The 'OR' is part of the problem. More than one way to do the
same thing is causing some of the incompatibility problems.


-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


------------=_1095106011-26400-115--

--=_mixed 006E590485256F0E_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
AQAAoIINcDCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZI
hvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4
MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rI
SsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+
MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG
+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY
UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5Jz
dC6JOzUTcudAMZrTssSr51a+i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBB
MPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQwHhcNMDQwOTAzMDAwMDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91
ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMWHYQKNX06SDOZPZvQOVD5lgC
2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4IaamL0bbVrINBtK
mW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo
0Y6uq+kkkPqYd+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQz
FWwe1UaHKYPb8d8xO6qGJNisRNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IH
nwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJBgNVHRMEAjAAMIGsBgNVHSAE
gaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM26zHybGdD0C7c
Q+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J3
8rgwggUBMIIEaqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEB
BAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAw
MFoXDTA1MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B
CQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAzFh2ECjV9OkgzmT2b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUE
k1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSpluabeSeXZhFTAZSp7mqR8kZM55
LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ+SIZOInZLPfU
iloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETS
N4vU/WT1Pv+IAvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IB
HDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT
aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcE
BhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp
4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPrGpYuUwn62iMbUSaGXYFlg0Am
2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOSzi6mbsF7ZSIc
2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wCQYF
Kw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMTk1ODEyWjAjBgkqhkiG9w0BCQQxFgQUERAauvzM
TspTgIzbsI2oR5ww7e0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90
IFZhbGlkYXRlZAIQV2Y2bnhVsEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsx
geSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg
U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wDQYJKoZIhvcNAQEBBQAEggEAPLFxgHq7em5qDbPLjA9DvTg1KqLC
7aSnFgO9QHM7TywX62v42SzjN6kY1nnWOv8BKymVEs/SImWIiB1NGMMv+fBa
X++0JZdM9fKDNYXgxUv+B62GUsZEDM6FvDMN9qzRJCHYDoxvvb30SlxYjg5v
2eNk/yHtdUudBe7LCf0/SU60eEvLivAvdbOlmKHg964iwHsPwI+fDeN7y/rD
BjmHRMtaV1Wy+67VtXlxzK1PRNU546Wh7Ify7F1bL6tAu1KPGcsAV6Vk9T/8
oYna3/lGIWhtYkS0P9gWOg2t7/RpkNqLrXCFsOTkKVRf4atS3ci0LdpQRPJW
i/KwzuhQzKInUQAAAAAAAA==

--=_mixed 006E590485256F0E_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DJwLpp002091 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 13 Sep 2004 12:58:22 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8DJwCSw020267 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 12:58:14 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 13:58:12 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060400010601040102010604"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] Changes by RID
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 19:58:23 -0000

This is a cryptographically signed message in MIME format.

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



[e-mail] wrote:

>Or you just send update using UID/SEQ/DTSTAMP and RID.  The RID is the 
>instance you want to change.
>  
>

I propose we deprecate that method of updates.

Just send the new objects as a replacement set.

Very few implementations support that model of changes. No real 
interoperablity.
Almost everyone sends entire replacement objects.

The 'OR' is part of the problem. More than one way to do the
same thing is causing some of the incompatibility problems.


-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms060400010601040102010604
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMTk1ODEyWjAjBgkqhkiG9w0BCQQxFgQUERAauvzMTspTgIzbsI2o
R5ww7e0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAPLFxgHq7em5qDbPLjA9DvTg1KqLC7aSnFgO9QHM7TywX62v42SzjN6kY1nnWOv8B
KymVEs/SImWIiB1NGMMv+fBaX++0JZdM9fKDNYXgxUv+B62GUsZEDM6FvDMN9qzRJCHYDoxv
vb30SlxYjg5v2eNk/yHtdUudBe7LCf0/SU60eEvLivAvdbOlmKHg964iwHsPwI+fDeN7y/rD
BjmHRMtaV1Wy+67VtXlxzK1PRNU546Wh7Ify7F1bL6tAu1KPGcsAV6Vk9T/8oYna3/lGIWht
YkS0P9gWOg2t7/RpkNqLrXCFsOTkKVRf4atS3ci0LdpQRPJWi/KwzuhQzKInUQAAAAAAAA==
--------------ms060400010601040102010604--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DJkdpo001392 for <[e-mail]>; Mon, 13 Sep 2004 12:46:40 -0700
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] reduced RRULE propsoal
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 13 Sep 2004 15:47:06 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 09/13/2004 03:43:45 PM
Content-Type: multipart/mixed; boundary="=_mixed 006C7FE785256F0E_="
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 19:46:40 -0000

This is a multi-part message in MIME format...

--=_mixed 006C7FE785256F0E_=
Content-Type: multipart/alternative; boundary="----------=_1095104800-26400-42"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095104800-26400-42
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

Or you just send update using UID/SEQ/DTSTAMP and RID.  The RID is the 
instance you want to change.



Doug Royer <[e-mail]> 
Sent by: [e-mail]
09/13/2004 03:25 PM
Please respond to
[e-mail]


To
[e-mail]
cc

Subject
Re: [Ietf-calsify] reduced RRULE propsoal








Cyrus Daboo wrote:

> Hi Doug,
>
> --On Monday, September 13, 2004 12:07 PM -0600 Doug Royer 
> <[e-mail]> wrote:
>
>> I also would like to restrict an object to zero or one RRULEs.
>>
>> Limit RRULE to one 'BY' rule (as someone else said).
>
>
> Do we do away with BYSETPOS? If so, that prevents a recurrence such as 
> 'the first weekday of the month'. If we keep BYSETPOS then we need to 
> allow it in addition to other BYxxx's in the RRULE.

Good question. I could go ether way.

>
>> We can already have 2 or more objects with the same UID, DTSTAMP,
>> and SEQUENCE that represents more instances of the same series
>> of meetings.  (As done by the ADD method).
>
>
> Here is a general question on the interpretation of the uniqueness of 
> UID/SEQ/RID: what you are suggesting above is that a calstore can have 
> multiple components with the same UID, but with perhaps differing SEQ. 

If they have different SEQ values then they are different revisions of 
the same
series of entries. The largest SEQ value is the newest revision. (see 
iTIP).

If they have the same UID/SEQ/DTSTAMP then they are all part of ONE entry:
If you have a meeting every Monday at 2pm in LOCATION: ROOM-1. Easy.

Now next week you have to meet in ROOM-2.

So you send TWO new objects. The original with an EXDATE of next week.
And a SECOND object with ONE instance for Monday 2pm of next week
with LOCATION: ROOM-2.  Both objects have the same UID/SEQ/DTSTAMP.

> If so, how are you supposed to do synchronisation (between CUA/CS) 
> with those since its not possible to tell the difference between them 
> other than by perhaps looking at the other properties in each component? 


That is the current model. You tell the difference because they all have 
the
same UID/SEQ/DTSTAMP values.

>
> My interpretation of ADD in iTIP was that the CUA that receives the 
> ADD adjusts its copy of the original (master) component by adding an 
> appropriate RDATE for the new instance and then adds a RECURRENCE-ID 
> to its copy of the new instance and stores that. That way the 
> UID/SEQ/RID properties remain unique in the client's store and each 
> component/instance can be uniquely addressed and synchronised.

ADD was added because other things can change and there is no  way
to represent the odd entry (one or more)  in one object (LOCATION for 
example). There
is no way to add LOCATION (for example) to the RDATE or EXDATE
so the only way is to represent that instance in a separate object with
the same UID/SEQ/DTSTAMP.

If multiple objects have the same UID;/SEQ/DTSTAMP then they are all
part of one logical entry. If they are 100% the same, then they are just
duplicates of each other.

You can meet every week day at 2pm in room-1.
Then if only Friday changes to room-2, you would modify
the original object to say Monday-Thursday, LOCATION:room-1
and ADD a second object for Friday only, LOCATION:room-2
All with the same UID/SEQ/DTSTAMP.

If the UID is not the same - not the same object.

If UID is the same and SEQ is not the same - the newer SEQ wins and 
older versions
are replaced.

If UID and SEQ are the same and  DTSTAMP is not the same,
then newer DTSTAMP wins and older DTSTAMPS are replaced as iTIP
says they are newer revisions of the same entry (perhaps spelling error 
fixed).

If UID/SEQ/DTSTAMP are the same - then they are all part
of the same logical entry.

The problem is when an appointment evolves over time. There
needed to be a way to represent that this series of entries really
is the same. You only need RDATE/RRULE/EXDATE when only the
date/time changes. When other things change then you have to
specify the series in multiple objects with same UID/SEQ/DTSTAMP.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


------------=_1095104800-26400-42--

--=_mixed 006C7FE785256F0E_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
AQAAoIINcDCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZI
hvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4
MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rI
SsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+
MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG
+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY
UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5Jz
dC6JOzUTcudAMZrTssSr51a+i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBB
MPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQwHhcNMDQwOTAzMDAwMDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91
ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMWHYQKNX06SDOZPZvQOVD5lgC
2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4IaamL0bbVrINBtK
mW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo
0Y6uq+kkkPqYd+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQz
FWwe1UaHKYPb8d8xO6qGJNisRNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IH
nwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJBgNVHRMEAjAAMIGsBgNVHSAE
gaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM26zHybGdD0C7c
Q+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J3
8rgwggUBMIIEaqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEB
BAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAw
MFoXDTA1MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B
CQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAzFh2ECjV9OkgzmT2b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUE
k1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSpluabeSeXZhFTAZSp7mqR8kZM55
LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ+SIZOInZLPfU
iloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETS
N4vU/WT1Pv+IAvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IB
HDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT
aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcE
BhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp
4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPrGpYuUwn62iMbUSaGXYFlg0Am
2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOSzi6mbsF7ZSIc
2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wCQYF
Kw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMTkyNTU5WjAjBgkqhkiG9w0BCQQxFgQUQepvqgZc
rmzHPVbSkPO1xCnzdrgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90
IFZhbGlkYXRlZAIQV2Y2bnhVsEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsx
geSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg
U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wDQYJKoZIhvcNAQEBBQAEggEAH5goIVPdZR/QVotMPTEU6p7rmCv9
5helM3X0B1vMfObdCqtVQ1BybgYUADAAISpq95slAkyTGwFMezGekGfXkrt0
wGSzwCsfm/zYfeeCWT7xSZWZvAjHX5C38w0bRGMXwRiffWq/IUssYndkIqST
N697pslsTqeDkJrFlKwVMSRSUL/yRvOE+olEK79GsBwSaJcTpBeezkGtdXOj
wAf1CbhCEaSym30u3Cl2PVXFeeGnW/uam7u4iOeUT2nrLO0O5kSBCuE3Ar93
uQhuPZ2SFTJoFVTc/QVi7teL5KfP8umu+Gfalkpw45tAeNesn33wpbB6NaIb
9pU6Pu7+Sy9SUwAAAAAAAA==

--=_mixed 006C7FE785256F0E_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DJQApp032711 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 13 Sep 2004 12:26:11 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8DJPxSw019895 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 12:26:01 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 13:25:59 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] reduced RRULE propsoal
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000701040708090808050100"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 19:26:12 -0000

This is a cryptographically signed message in MIME format.

--------------ms000701040708090808050100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Cyrus Daboo wrote:

> Hi Doug,
>
> --On Monday, September 13, 2004 12:07 PM -0600 Doug Royer 
> <[e-mail]> wrote:
>
>> I also would like to restrict an object to zero or one RRULEs.
>>
>> Limit RRULE to one 'BY' rule (as someone else said).
>
>
> Do we do away with BYSETPOS? If so, that prevents a recurrence such as 
> 'the first weekday of the month'. If we keep BYSETPOS then we need to 
> allow it in addition to other BYxxx's in the RRULE.

Good question. I could go ether way.

>
>> We can already have 2 or more objects with the same UID, DTSTAMP,
>> and SEQUENCE that represents more instances of the same series
>> of meetings.  (As done by the ADD method).
>
>
> Here is a general question on the interpretation of the uniqueness of 
> UID/SEQ/RID: what you are suggesting above is that a calstore can have 
> multiple components with the same UID, but with perhaps differing SEQ. 

If they have different SEQ values then they are different revisions of 
the same
series of entries. The largest SEQ value is the newest revision. (see iTIP).

If they have the same UID/SEQ/DTSTAMP then they are all part of ONE entry:
If you have a meeting every Monday at 2pm in LOCATION: ROOM-1. Easy.

Now next week you have to meet in ROOM-2.

So you send TWO new objects. The original with an EXDATE of next week.
And a SECOND object with ONE instance for Monday 2pm of next week
with LOCATION: ROOM-2.  Both objects have the same UID/SEQ/DTSTAMP.

> If so, how are you supposed to do synchronisation (between CUA/CS) 
> with those since its not possible to tell the difference between them 
> other than by perhaps looking at the other properties in each component? 

That is the current model. You tell the difference because they all have the
same UID/SEQ/DTSTAMP values.

>
> My interpretation of ADD in iTIP was that the CUA that receives the 
> ADD adjusts its copy of the original (master) component by adding an 
> appropriate RDATE for the new instance and then adds a RECURRENCE-ID 
> to its copy of the new instance and stores that. That way the 
> UID/SEQ/RID properties remain unique in the client's store and each 
> component/instance can be uniquely addressed and synchronised.

ADD was added because other things can change and there is no  way
to represent the odd entry (one or more)  in one object (LOCATION for 
example). There
is no way to add LOCATION (for example) to the RDATE or EXDATE
so the only way is to represent that instance in a separate object with
the same UID/SEQ/DTSTAMP.

If multiple objects have the same UID;/SEQ/DTSTAMP then they are all
part of one logical entry. If they are 100% the same, then they are just
duplicates of each other.

You can meet every week day at 2pm in room-1.
Then if only Friday changes to room-2, you would modify
the original object to say Monday-Thursday, LOCATION:room-1
and ADD a second object for Friday only, LOCATION:room-2
All with the same UID/SEQ/DTSTAMP.

If the UID is not the same - not the same object.

If UID is the same and SEQ is not the same - the newer SEQ wins and 
older versions
are replaced.

If UID and SEQ are the same and  DTSTAMP is not the same,
then newer DTSTAMP wins and older DTSTAMPS are replaced as iTIP
says they are newer revisions of the same entry (perhaps spelling error 
fixed).

If UID/SEQ/DTSTAMP are the same - then they are all part
of the same logical entry.

The problem is when an appointment evolves over time. There
needed to be a way to represent that this series of entries really
is the same. You only need RDATE/RRULE/EXDATE when only the
date/time changes. When other things change then you have to
specify the series in multiple objects with same UID/SEQ/DTSTAMP.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms000701040708090808050100
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMTkyNTU5WjAjBgkqhkiG9w0BCQQxFgQUQepvqgZcrmzHPVbSkPO1
xCnzdrgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAH5goIVPdZR/QVotMPTEU6p7rmCv95helM3X0B1vMfObdCqtVQ1BybgYUADAAISpq
95slAkyTGwFMezGekGfXkrt0wGSzwCsfm/zYfeeCWT7xSZWZvAjHX5C38w0bRGMXwRiffWq/
IUssYndkIqSTN697pslsTqeDkJrFlKwVMSRSUL/yRvOE+olEK79GsBwSaJcTpBeezkGtdXOj
wAf1CbhCEaSym30u3Cl2PVXFeeGnW/uam7u4iOeUT2nrLO0O5kSBCuE3Ar93uQhuPZ2SFTJo
FVTc/QVi7teL5KfP8umu+Gfalkpw45tAeNesn33wpbB6NaIb9pU6Pu7+Sy9SUwAAAAAAAA==
--------------ms000701040708090808050100--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DIngpp029492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 11:49:43 -0700
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i8DITdo3009795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 14:29:40 -0400
Date: Mon, 13 Sep 2004 14:49:40 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] reduced RRULE propsoal
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 18:49:44 -0000

Hi Doug,

--On Monday, September 13, 2004 12:07 PM -0600 Doug Royer <[e-mail]> 
wrote:

> I also would like to restrict an object to zero or one RRULEs.
>
> Limit RRULE to one 'BY' rule (as someone else said).

Do we do away with BYSETPOS? If so, that prevents a recurrence such as 'the 
first weekday of the month'. If we keep BYSETPOS then we need to allow it 
in addition to other BYxxx's in the RRULE.

> We can already have 2 or more objects with the same UID, DTSTAMP,
> and SEQUENCE that represents more instances of the same series
> of meetings.  (As done by the ADD method).

Here is a general question on the interpretation of the uniqueness of 
UID/SEQ/RID: what you are suggesting above is that a calstore can have 
multiple components with the same UID, but with perhaps differing SEQ. If 
so, how are you supposed to do synchronisation (between CUA/CS) with those 
since its not possible to tell the difference between them other than by 
perhaps looking at the other properties in each component?

My interpretation of ADD in iTIP was that the CUA that receives the ADD 
adjusts its copy of the original (master) component by adding an 
appropriate RDATE for the new instance and then adds a RECURRENCE-ID to its 
copy of the new instance and stores that. That way the UID/SEQ/RID 
properties remain unique in the client's store and each component/instance 
can be uniquely addressed and synchronised.


-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DI7Ipp025943 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 13 Sep 2004 11:07:19 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8DI7ASw018905 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 11:07:11 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 12:07:10 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] reduced RRULE propsoal
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060304090905080302080305"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 18:07:20 -0000

This is a cryptographically signed message in MIME format.

--------------ms060304090905080302080305
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Curt Ellmann wrote:

>Would annual recurring events e.g. each year on July 4th be supported?
>Also, would biweekly or bimonthly events be allowed?
>

(1) Annual:

    BYMONTH allows for that.

        DTSTART: 20040101
        RRULE:FREQ=YEARLY;BYMONTH=1

   Or they could be a series of RDATEs.

(2) Weekly or more than once a week.

   The BYDAY rule allow for comma separated values already.

    DTSTART:20040913T120000Z
    RRULE;FREQ=WEEKLY;BYDAY=MO,TH

(3) Monthly or more than once a month:

    MYMONTHDAY supports a comma separated list of dates already.

    DTART:20040913T120000Z
    RRULE:FREQ=MONTHLY;BYMONTHDAY=1,13


I also would like to restrict an object to zero or one RRULEs.

Limit RRULE to one 'BY' rule (as someone else said).

We can already have 2 or more objects with the same UID, DTSTAMP,
and SEQUENCE that represents more instances of the same series
of meetings.  (As done by the ADD method).

Once we all agree, I can write up the new ABNF and submit it.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms060304090905080302080305
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMTgwNzEwWjAjBgkqhkiG9w0BCQQxFgQUj4HZKUXqUBsMR00bl4x2
x/gis/owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAB4OlwewubDqoUcB2cAqoYIZAlfrOa6Tk7s3y+ZkyhmJP8yY3n3tR34XWPWURvy0O
ibfouo7APMlaORXN6rFW1mh4i9TF0lC7CEKuffdaR5EteWgcNna5TFLuCWm36QULbwvUteLa
MBQMts1KrWPj3MKEwqFy48gHurZkNoofs7xeNKje9HXUQDcCVLWLTXC2Amv6ohboqyoFCdvl
AvXTk3wvNtNv77LKJ9i7kt/tLf0VPT94rEckn4z94JQKf0SIPjXwm9LwCtP+9gOh5tqDBrGy
uqZ6u2yRrmeuiHEuxrsLMcNw8F5ivIB+GciR6u8O4EvzflijS4o0NsjX6wUtNAAAAAAAAA==
--------------ms060304090905080302080305--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp4.wiscmail.wisc.edu (hermes.doit.wisc.edu [144.92.197.190]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DHkcpo023899 for <[e-mail]>; Mon, 13 Sep 2004 10:46:38 -0700
Received: from avs-daemon.smtp4.wiscmail.wisc.edu by smtp4.wiscmail.wisc.edu (iPlanet Messaging Server 5.2 HotFix 1.26 (built Mar 31 2004)) id <[e-mail]> for [e-mail]; Mon, 13 Sep 2004 12:46:33 -0500 (CDT)
Received: from Sedna (dyn-4-227.doit.wisc.edu [128.104.4.227]) by smtp4.wiscmail.wisc.edu (iPlanet Messaging Server 5.2 HotFix 1.26 (built Mar 31 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 13 Sep 2004 12:46:31 -0500 (CDT)
Date: Mon, 13 Sep 2004 12:46:22 -0500
From: Curt Ellmann <[e-mail]>
Subject: RE: [Ietf-calsify] reduced RRULE propsoal
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcSZuGa+M1KxMDxRRuq0Ei7NNy5zGAAALCug
X-Spam-Report: TrustedSender=yes, SenderIP=128.104.4.227
X-Spam-PmxInfo: Server=avs-6, Version=4.7.0.111621, Antispam-Engine: 2.0.0.0,  Antispam-Data: 2004.9.13.0, SenderIP=128.104.4.227
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 17:46:39 -0000

Would annual recurring events e.g. each year on July 4th be supported?
Also, would biweekly or bimonthly events be allowed?

-curt.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Doug Royer
Sent: Monday, September 13, 2004 11:37 AM
To: [e-mail]
Subject: [Ietf-calsify] reduced RRULE propsoal



I propose:


(1) We deprecate EXRULE. I have not seen a CUA that allows
the CU to create one. And it can be emulated with EXDATE.

(2) Allow recurrences only for:
      
    Day of month (Every 1st, 2nd, ...)
    Day of week  (Every Sunday, Monday, ...)



-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards





X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8DHaupp023166 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 13 Sep 2004 10:36:59 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8DHaiSw018415 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 13 Sep 2004 10:36:46 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 11:36:43 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050704090405020607050101"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] reduced RRULE propsoal
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 17:37:00 -0000

This is a cryptographically signed message in MIME format.

--------------ms050704090405020607050101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



I propose:


(1) We deprecate EXRULE. I have not seen a CUA that allows
the CU to create one. And it can be emulated with EXDATE.

(2) Allow recurrences only for:
      
    Day of month (Every 1st, 2nd, ...)
    Day of week  (Every Sunday, Monday, ...)



-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms050704090405020607050101
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEzMTczNjQzWjAjBgkqhkiG9w0BCQQxFgQU4Gyb1vMrp7OCjo/tJyPp
T4K8lXEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAIlr5U4yGp7BRMad51EqN6t1rTETu5LV1o09iKTCVp5siYRKwxrE9PErz+fDhemoV
zZV8HAiXNPyBgLFfPMYwb8qSeIY8hyLmOVjgTqAhIat2NcmzqOCGnIgR6SFcTdjoPllw79sv
o96QMJ8t5rw7nGjFTqRKdulfSr2h2LgYmUNRzGN8p3h576WdnQhJgJsZcV6/lKrD79WfBb2o
O9tPSfTB7ORfDIOKVGdO++yc1QZKXvtuaYRnVkS5oXhuWZ/D8u112+2o2PaLSW66PHBBifIg
4FOlgOI7SH+P62AEZKyOldRTImjSJL/15KvSWFnyMmNKhx2gz+Cjw46em6nVzwAAAAAAAA==
--------------ms050704090405020607050101--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8B08Qpp032166 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 10 Sep 2004 17:08:28 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8B08CSw017013 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 10 Sep 2004 17:08:14 -0700
Message-ID: <[e-mail]>
Date: Fri, 10 Sep 2004 18:08:11 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
References: <[e-mail]> <1094855069.6086.489.camel@dirk>
In-Reply-To: <1094855069.6086.489.camel@dirk>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000608000702030300070901"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Sep 2004 00:08:29 -0000

This is a cryptographically signed message in MIME format.

--------------ms000608000702030300070901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>I must say that seems like a strange thing to do, just when the
>various tools are starting to get it right. The spec for VTIMEZONE
>seems like a pretty good match for the widely-deployed Olsen
>timezone database. It's maybe slightly hairier than it
>needs to be, in theory; I can imagine pruning the allowed
>RRULE constructs a bit. But in practice, it seems to work
>nicely.
>
>  
>
Part of the debate on this list was to change RRULE. This effected
recurring events across time zones.  Also included in this debate was
how to have the client do TZ math. And VTIMEZONE contains
RRULEs and can include RDATEs.

Also in the debate on this list was listing all entries in UTC.  This
would eliminate the need for VTIMEZONE in many (all?) components.
Yet the CUA still needs to do TZ math.  So this is a proposal on
how to have simple IANA registered time zones so that everyone does
the same math.

I have modeled the proposed XML format to be compatible with the zdump 
output
format from the compiled Olson database. A simple hack to zdump should
be able to produce this XML object directly.

No need to pass the same time zone definition in each component
each time any more.


-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms000608000702030300070901
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTExMDAwODExWjAjBgkqhkiG9w0BCQQxFgQUuv8d/huFzt6HwpSGTI4L
g8i+ThswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAX7zEG2DDgLAGD/Lw81z59l0zo1iaYFWpBW0S4/Q0+FY+OGEiBenaTBtHubXLXQRh
pR9YOhVhiWczoE6T4teCUGFluAp83EEs5IAuCCu44GhFbhONRAZZ0OAsltqQ3ok1bhorFgkJ
Cu1LvYZPzJGOmuoy8okHTNOE1q4x5aY6clP4caTsb1VEsZeYOAtMhiL/HWi/JxfFywIt4niR
ACVp9n/s+ktayoXDVRjMhyQGPubVSm3QMpL+GlIKT27QyT/3DXwgFTnHSubjoILPefIY6m8O
+q3Qh+1OlofmU+lRwceH+ySQkMvWLq61FGnXEqecJ2LpFlj4jCwbLaJ7IJ9jWAAAAAAAAA==
--------------ms000608000702030300070901--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8AMOBpo027890 for <[e-mail]>; Fri, 10 Sep 2004 15:24:11 -0700
Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id B447B4EED2; Fri, 10 Sep 2004 18:24:10 -0400 (EDT)
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
From: Dan Connolly <[e-mail]>
To: Libby Miller <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Organization: World Wide Web Consortium (http://www.w3.org/)
Message-Id: <1094855069.6086.489.camel@dirk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Fri, 10 Sep 2004 17:24:29 -0500
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.39
X-Mailman-Approved-At: Fri, 10 Sep 2004 16:04:26 -0700
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2004 22:24:13 -0000

On Fri, 2004-09-10 at 02:43, Libby Miller wrote:
> from the new icalendar mailing list.

Have you told them about our repository of timezone data in XML?
 http://www.w3.org/2002/12/cal/#tzd

Would you please? If not you, is anybody else watching both lists?

http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Hmm... I think I'll just cross-post and hope for the best...

Doug Royer wrote:
> My idea is to deprecate the VTIMEZONE object in VCALENDAR objects

I must say that seems like a strange thing to do, just when the
various tools are starting to get it right. The spec for VTIMEZONE
seems like a pretty good match for the widely-deployed Olsen
timezone database. It's maybe slightly hairier than it
needs to be, in theory; I can imagine pruning the allowed
RRULE constructs a bit. But in practice, it seems to work
nicely.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8AM04pp026801 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 10 Sep 2004 15:00:05 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8ALxnSw015016 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 10 Sep 2004 14:59:51 -0700
Message-ID: <[e-mail]>
Date: Fri, 10 Sep 2004 15:59:49 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>, [e-mail]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040808080002000408040301"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Cc: 
Subject: [Ietf-calsify] [Fwd: I-D ACTION:draft-royer-calsch-xmltz-00.txt]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2004 22:00:06 -0000

This is a cryptographically signed message in MIME format.

--------------ms040808080002000408040301
Content-Type: multipart/mixed; boundary="------------050901010906080100080205"

This is a multi-part message in MIME format.
--------------050901010906080100080205
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


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


	Title		: Time Zones in XML
	Author(s)	: D. Royer
	Filename	: draft-royer-calsch-xmltz-00.txt
	Pages		: 15
	Date		: 2004-9-10
	
The iCalendar data format is being updated and included in those
   discussions is the desire to update the time zone information. This
   is a proposal for time zone updates to iCalendar. The time zone
   information will be available in XML format. To comment on this
   document send email to [e-mail] .


   This document also specifies an IANA registration process for time
   zones. No attempt is made to specify any specific time zones as that
   is political information that is out of scope for this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-royer-calsch-xmltz-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-royer-calsch-xmltz-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-royer-calsch-xmltz-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------050901010906080100080205
Content-Type: Message/External-body;
 name="draft-royer-calsch-xmltz-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-royer-calsch-xmltz-00.txt"

Content-Type: text/plain
Content-ID: <[e-mail]>



--------------050901010906080100080205
Content-Type: text/plain;
 name="file:///tmp/nsmail.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="file:///tmp/nsmail.txt"

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce


--------------050901010906080100080205--

--------------ms040808080002000408040301
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEwMjE1OTQ5WjAjBgkqhkiG9w0BCQQxFgQUeO0de2sWyA9EvHonLzhm
fptFANAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAUHgzzkQjJv/7NVn8qkL9wjTJ3NfXWDqxkBkXRzc2jWuGWrMiOb3dXOfirBuAcZrC
CErHGouaXobTufoz9UaLF9XrCufWxzOAaFvcM+9C8x0oIOXt/fZM3hcFUK0JbvrM/H1PROG/
L3WVg/UAFyhu2JeM7sVe91ZeorvnVtjgzYBL+q/oNrm4B/H2UE6VdQW4ERKTIqZqOfprl94W
d3ezh9Hs299bpao6oz2ow4IIl9VL0c8RMjszDIj6qg1VqmMFG6fP0/AuEZL5nZER185lPA2i
AegRIIuTtOGBU0RpyLu0Vl3dKrAD6wUmDmx073zdItzDOE6wekT/C6rGpdgd4AAAAAAAAA==
--------------ms040808080002000408040301--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8A3vrpp032587 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Thu, 9 Sep 2004 20:57:54 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8A3viSw031973 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 9 Sep 2004 20:57:46 -0700
Message-ID: <[e-mail]>
Date: Thu, 09 Sep 2004 21:57:44 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040408030007050902050305"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] VTIMEZONE - replacement idea
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2004 03:57:56 -0000

This is a cryptographically signed message in MIME format.

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


I submitted draft-royer-calsch-xmltz-00.txt and it should
being showing up in a few days on the IETF announce list.

My idea is to deprecate the VTIMEZONE object in VCALENDAR objects
and only include the TZID.

Then allow applications to find IANA registered time zones
in XML format that describe the named time zone. They can
cache in local storage the TZID/revision and do the timezone
math much easier.

The XML format is a simplified and revision controlled time zone
definition. Instead of including RRULEs, it enumerates the exact
UTC date/time change and its offset in seconds. An application
would just need to find the TZID, scan for a matching time
range and add/subtract from UTC.

The draft has place holders for a URL specification for fetching
by TZID.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms040408030007050902050305
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTEwMDM1NzQ0WjAjBgkqhkiG9w0BCQQxFgQUq1h/FGnwy3ajZZSpFPT6
oPpteUQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAZOJLI5BUHGe05tCmGjkx805bquT5r8aSqbXvlDI5UEJxihZXQcr+ZbByxIW4hLIK
VbSsPRfnCxL3pCLQGWe7Px4it73MY+c80e/nMKI4x5vjFpn9CXwTkcc+jVi4QNvCMdC8syCg
XSuEvdBgrU1180RWF+7v7QmWK3xwMD7jef+iO6Ltmd5tAaKzT7Q6R7475dcb+lC991nuaduf
Aq4oQQrIdT1W66/vR0IFa3EFhE2XHsWnSqIY16D4eogJzkOy2ziG2ei2u0vGWrrU4cS0qG1f
t38DBu76NbZeiX4+xz70u2L2efGJ/SZEaFGrul9SksnKdQS2cglVAVJBr9aiFwAAAAAAAA==
--------------ms040408030007050902050305--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8A157po021340 for <[e-mail]>; Thu, 9 Sep 2004 18:05:07 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc11) with SMTP id <200409100105010130055qh5e> (Authid: TimHare); Fri, 10 Sep 2004 01:05:01 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Thu, 09 Sep 2004 21:04:34 -0400
To: Nathaniel Borenstein <[e-mail]>
From: [e-mail]
Subject: Re: [Ietf-calsify] Aiding the process (I hope)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2004 01:05:07 -0000

Can we take the table that Nathaniel posted and/or the XML that I posted, 
and use that to decide which elements need simplification, revision, or 
omission? So far, the only thing that's come close to consensus is the idea 
of using only UTC when exchanging iCalendar objects. I'm sure there are 
others we can come close on. Another useful tactic might be to try to 
enumerate the _minimum_ functions needed based on use cases of "Joe User" 
and "Jane User" on different platforms and decide what elements are needed 
to accomplish those, rather than thinking about what elements are required 
to handle what currently exists in the various implementations. My view, as 
a user, is that even though there's a lot of function in the products out 
there, not all of that function is required for interoperability - perhaps 
there is a "lingua franca" for interoperability which will meet our 
simplification needs.


At 01:10 PM 8/28/04, Nathaniel Borenstein wrote:

>On Aug 26, 2004, at 12:22 AM, [e-mail] wrote:
>
>>In an effort to get a handle on things, I've built this file (attached) 
>>to document the major elements of RCF2445/6/7 and CAP-13. It's in XML, 
>>because....
>
>Although Tim's reasons for xml make sense, naturally the first thing I did 
>was convert it to an HTML table.  So I thought I'd share that with anyone 
>who hasn't actually tried to read the file yet...
>
>
>
>
>
>
>Thanks, Tim.  -- Nathaniel

Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i88Fonpp030003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 8 Sep 2004 08:50:50 -0700
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i88FVVo3010266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Sep 2004 11:31:32 -0400
Date: Wed, 08 Sep 2004 11:50:44 -0400
From: Cyrus Daboo <[e-mail]>
To: Cameron Stillion <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail] rp.microsoft.com>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Scanned-By: MIMEDefang 2.39
Cc: 
Subject: [Ietf-calsify] Alarm properties and standalone alarm model, was Re: possible VALARM solution?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Sep 2004 15:50:50 -0000

Hi Cameron,

--On Tuesday, September 7, 2004 11:22 PM -0700 Cameron Stillion 
<[e-mail]> wrote:

> I like the idea of the "off switch" for alarms, especially since we
> implement reminders that way internally... Perhaps this is an extension
> we should adopt in the standard in the spirit of simplicity in the
> flavor of interoperability.  But of course, clients should still be
> smart when alarms are not explicitly disabled.

In my client I ended up implementing two private x-props to handle alarms 
(in particular repeating alarms and alarms on recurring events/to-dos). The 
two are:

1) A status property with three possible values:

   - 'PENDING' - means the alarm is active and the client needs to monitor 
it to see
                 when it is triggered, or whether it should have already 
been triggered
                 (i.e. client session was started after trigger time). 
Determing the next
                 trigger is based on the 'LAST-TRIGGER' property described 
below.

   - 'COMPLETED' - means the alarm has been signaled to the user and there 
is no need
                   for the client to monitor it further. This provides a 
useful shortcut
                   for the client as it means it can ignore the alarm 
altogether - no need
                   to determine trigger time etc

   - 'DISABLED' - means the user has explicitly disabled the alarm so the 
client does not
                  need to monitor it.

2) A 'LAST-TRIGGER' property with a date-time value. This indicates the 
last time the alarm was triggered and is used to track which triggers in a 
repeating alarm have already been signaled. This provides a smart way for 
the client to know whether it needs to signal an alarm that would have 
occurred prior to the current session.

'LAST-TRIGGER' is a necessity in my mind for handling repeating/recurring 
alarms. I think the status indicator is also required, as this thread has 
shown.

In addition I would also like to argue for a change in the VALARM component 
- specifically the ability to have a VALARM be a 'primary' component like 
VEVENT/VTODO etc - i.e. its not limited to being embedded inside another 
component. Part of the current problem with alarms for one user 'leaking 
out' to others is that the alarm data is embedded in the event so it gets 
transported with that event. By separating the alarm from the event, there 
is a clear distinction between the two and less chance of leakage of 
per-user alarm data. The other advantage is that it allows for the option 
to use a 'library' of standard alarm behaviours (e.g. 'five minutes 
before', '30 minutes before' etc) which can then be linked to the 
events(i.e. one alarm component can be used to trigger multiple alarms on 
different events). I suspect most people use pretty much the same type of 
alarm behaviours time after time so this would save on storage.

The big disadvantage to the separate alarm model is maintaining the correct 
links between the alarms and the events/to-dos. Ideally the links should 
only be in the alarm component, say by the use of a 'RELATED-TO' property 
containing the UID of the event/to-do that the alarm applies to (multiple 
'RELATED-TO's would be allowed to enable the alarm 'library' capability).

Obviously this is a significant change to iCal - but I think it would be 
worth it. Note that the current design of caldav actually does split alarms 
out into a separate webdav collection, though there is some debate about 
that. Also, CAP had to go through all kinds of twists in order to be able 
to handle per-user alarms on shared events etc with the current embedded 
alarm model.

-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i886Mapo026435 for <[e-mail]>; Tue, 7 Sep 2004 23:22:36 -0700
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);  Tue, 7 Sep 2004 23:22:36 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 07 Sep 2004 23:22:35 -0700
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 23:22:35 -0700
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 23:22:35 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] Re: possible VALARM solution?
Date: Tue, 7 Sep 2004 23:22:33 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] Re: possible VALARM solution?
thread-index: AcSVQKD5GqDKGptrQDSeIXJIEdc90QAK0Wgg
From: "Cameron Stillion" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 08 Sep 2004 06:22:35.0479 (UTC) FILETIME=[3B295E70:01C4956C]
X-Scanned-By: MIMEDefang 2.39
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i886Mapo026435
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Sep 2004 06:22:37 -0000

I like the idea of the "off switch" for alarms, especially since we
implement reminders that way internally... Perhaps this is an extension
we should adopt in the standard in the spirit of simplicity in the
flavor of interoperability.  But of course, clients should still be
smart when alarms are not explicitly disabled.


Cameron


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Doug Royer
Sent: Tuesday, September 07, 2004 6:09 PM
To: [e-mail]
Subject: [Ietf-calsify] Re: possible VALARM solution?



[e-mail] wrote:

> Right - but _adding_  objects/components/properties takes us away from

> our simplification goal, and simplification is being discussed to 
> improve interoperability.

Yes it adds. Interoperability is the other goal. And that is part of
this debate.

Its simply a standardized way to tag the data so that cross vendors can
tell tell that the CU already answered your questions.

If you get a PUBLISH with a VALARM, the user says don't set them.
Do you delete the alarm and store the object without the alarm?
Or do you somehow remember that the alarm is to be ignored?

Now you get an update to that PUBLISHed object (which still contains its
valarm) , the LOCATION is changed, do you ask again?

Or do you remember that you said no to the alarm? How? Does your way
work with another vendor?

If you deleted the valarm then the new update looks like a new alarm -
correct?
So you ask again and delete it again?

The CAP solution was to store the VALARM with a ENABLE=FALSE parameter
and not delete the valarm. Now you know that UID:123 VALARM is to be
ignored from any vendors CUA no matter how may updates are sent to the
same object.

This also solves the problem of unwanted action types
(PROCEDURE/AUDIO/...) alarms
from imported alarms that may be updated over time. The CUA can always
set PROCEDURE alarms to disabled in a way that other CUAs can tell.

Its not simple if its not interoperable.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards





X-Envelope-From: [e-mail]
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i881iLpo027009; Tue, 7 Sep 2004 18:44:21 -0700
In-Reply-To: <[e-mail]>
To: Elias Sinderson <[e-mail]>
Subject: Re: [Ietf-calsify] Event classes
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 7 Sep 2004 21:44:19 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 09/07/2004 09:44:21 PM, Serialize complete at 09/07/2004 09:44:21 PM
Content-Type: multipart/alternative; boundary="=_alternative 00098D3F85256F09_="
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Sep 2004 01:44:22 -0000

This is a multi-part message in MIME format...

--=_alternative 00098D3F85256F09_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

I agree.

Elias wrote: 
<snip> 
>Defining new access control mechanisms for iCal 
>introduces unnecessary complexity, fractures the existing specification 
>landscape and takes us farther away from the stated goal of 
>interoperability and standardization.

Pregen



Elias Sinderson <[e-mail]> 
Sent by: [e-mail]
09/07/2004 13:00

To
[e-mail]
cc

Subject
Re: [Ietf-calsify] Event classes






Doug Royer wrote:

> Great idea. New implementations will know what to do with them. RFC 
> 2445 defined the CLASS value to include 'iana-token'.
> Existing implementations should default to PUBLIC as defined in 2445 
> for CLASS when they do not understand the value.
> And we deprecate CONFIDENTIAL and PRIVATE. 

+1 - given that there is no interoperability wit respect to CONFIDENTIAL 
and PRIVATE event classes among existing implementations, they should be 
deprecated. Also, it should be noted that introducing additional event 
classes does not further the interoperability goals of the iCal 
standardization effort.

Personally, I do not feel that it is appropriate to definine access 
control mechanisms within this specification at all. Servers should 
implement and utilize existing interoperable access control mechanisms 
for iCal access. Defining new access control mechanisms for iCal 
introduces unnecessary complexity, fractures the existing specification 
landscape and takes us farther away from the stated goal of 
interoperability and standardization.


Regards,
Elias
_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


--=_alternative 00098D3F85256F09_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8818opp025561 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Tue, 7 Sep 2004 18:08:52 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8818dSw021177 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 7 Sep 2004 18:08:41 -0700
Message-ID: <[e-mail]>
Date: Tue, 07 Sep 2004 19:08:39 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020502010205020204030806"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] Re: possible VALARM solution?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Sep 2004 01:08:53 -0000

This is a cryptographically signed message in MIME format.

--------------ms020502010205020204030806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



[e-mail] wrote:

> Right - but _adding_  objects/components/properties takes us away from 
> our simplification goal, and simplification is being discussed to 
> improve interoperability. 

Yes it adds. Interoperability is the other goal. And that is part of 
this debate.

Its simply a standardized way to tag the data so that cross vendors can tell
tell that the CU already answered your questions.

If you get a PUBLISH with a VALARM, the user says don't set them.
Do you delete the alarm and store the object without the alarm?
Or do you somehow remember that the alarm is to be ignored?

Now you get an update to that PUBLISHed object (which still
contains its valarm) , the LOCATION is changed, do you ask again?

Or do you remember that you said no to the alarm? How? Does your
way work with another vendor?

If you deleted the valarm then the new update looks like a new alarm - 
correct?
So you ask again and delete it again?

The CAP solution was to store the VALARM with a ENABLE=FALSE
parameter and not delete the valarm. Now you know that UID:123 VALARM is 
to be ignored
from any vendors CUA no matter how may updates are sent to the same object.

This also solves the problem of unwanted action types 
(PROCEDURE/AUDIO/...) alarms
from imported alarms that may be updated over time. The CUA can always set
PROCEDURE alarms to disabled in a way that other CUAs can tell.

Its not simple if its not interoperable.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms020502010205020204030806
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTA4MDEwODM5WjAjBgkqhkiG9w0BCQQxFgQUIVL+0VIwGrXo8h9tr3w+
lKhkevswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAlEESBgojnslY5D97FPs4+WeeCgOqS6epClIN+jhg19J94UdWmIyQlex7nSizQXYA
EMqziCPPplcQIZ5rfNJN7tgvBIZhNUhcCY3nqfdMT2vDk1QORrjWNxnXPC9gM+rYJ6bVI0h2
MuFBWbZ5rFgvbk+kdEe2QYjBLZJnuaqDGammrZfi3ZPTUSbij3VQRVbt5OWxy6ZH4xHsEDYp
KNCjBcBAm7Fw/yiciE0/LyV5nCnATnl7NfS0v8IWRZYhTi5eO24ZK7/+IADcn5Ciper9JDPm
8tYraXnXMGHkq19iuX4cHUjlVIxOdeWx0wyX3vv23L2nOfrUkJQZRygVih7PngAAAAAAAA==
--------------ms020502010205020204030806--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i880Depo022831 for <[e-mail]>; Tue, 7 Sep 2004 17:13:40 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc13) with SMTP id <2004090800133401500smjhee> (Authid: TimHare); Wed, 8 Sep 2004 00:13:35 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Tue, 07 Sep 2004 20:05:35 -0400
To: [e-mail]
From: [e-mail]
Subject: Re: [Fwd: Re: [Ietf-calsify] possible VALARM solution?]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Sep 2004 00:13:40 -0000

Right - but _adding_  objects/components/properties takes us away from our 
simplification goal, and simplification is being discussed to improve 
interoperability.

The many pieces of CAP are there to try to accomodate almost everything 
that existing implementations do - which is a different way to accomplish 
interoperability, but not a simple one.


At 02:13 PM 9/7/04, Doug Royer wrote:


>CAP adds a LOCAL and ENABLE objects to VALARM for just that purpose




Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i87IE7pp014809 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Tue, 7 Sep 2004 11:14:09 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i87IDvSw014979 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 7 Sep 2004 11:13:59 -0700
Message-ID: <[e-mail]>
Date: Tue, 07 Sep 2004 12:13:56 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: Re: [Ietf-calsify] possible VALARM solution?]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010708030404060606080403"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2004 18:14:10 -0000

This is a cryptographically signed message in MIME format.

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


[resend - sent to wrong list...]

[e-mail] wrote:

> It would be desirable for the UI of a CUA to ask you, at import/open 
> time, whether you want to:
>
>         1. Ignore alarms entirely - don't set them.
>         2. Import the alarms using client defaults
>         3. Ask the user what kind of alarm to set, for each one imported
>
> UIs of course, are outside of the scope of the simplification work - 
> but the above 3 choices would work whether we retain the transmission 
> of VALARMs, or we simplify by having a REMINDER=YES/NO 
> parameter/property.

CAP adds a LOCAL and ENABLE objects to VALARM for just that purpose.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards




--------------ms010708030404060606080403
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTA3MTgxMzU2WjAjBgkqhkiG9w0BCQQxFgQUeq+CBSSZJ1mx8njo/Jre
DN7qdtowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAWe6s9ZVmLmJWoDMlWJb7u+2ICqyh96uHz0kHtAAgm1RriBO0NgN+2+Ki2zWJadPz
pNR5CWgLGj8oB6lM2rYC1s9ezsmb3zHty0pvrLb19oukpwd3rCL/8Oa+/ujdDvtYyt1EhPsF
dZ5y9b0yn8p5PferT3OftXLA/f+PcDJYDdrKZF3zTnjKHu8VIIMCP+bmhAW3cfBfkTLsKazk
6Q6W5uyrDBMv8rVZkfjxT/6Bf1/osQ7prNjsvS7xmXKEUgX/giv9PhYkZrdKMUJBT0hte0og
T9owOZrnio1wpNTNkIO/xbO1WQ6bzVr+Np7EwAKDMHkdD5hXEuyU9H28DRu1zQAAAAAAAA==
--------------ms010708030404060606080403--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i87HhCpp012743 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Tue, 7 Sep 2004 10:43:13 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i87HgwSw014282 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 7 Sep 2004 10:43:01 -0700
Message-ID: <[e-mail]>
Date: Tue, 07 Sep 2004 11:42:57 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] (past alarms) possible VALARM solution?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080903010506080803060907"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2004 17:43:14 -0000

This is a cryptographically signed message in MIME format.

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



Cameron Stillion wrote:

>The published calendar is more to the point.  Firing lots of past event
>alarms will not help you make the meeting, it will only cause noise that
>you will likely dismiss inadvertently to avoid the potentially many
>other pointless alarms.  Even so, this is a very small edge case of
>importing these events *just* as the event is starting.  Your CUA could
>realistically be smart enough to fire alarms for events that are also in
>process.
>  
>
That is an implementation detail - not a protocol issue or an object issue.

The purpose of iCAL is to define how to transport calendar objects.
Clearly VALARM is one of the successful objects being transported
at this time.

I can see a usage document for interpersonal calendaring describing
how/when/if a VALARM should be transported. However VALARM
is clearly compatible with many implementations at this time. So I do
not think that it is in scope to consider eliminating them entirely. And
if you can not transport them, that is the same effect.

I could PUBLISH a project calendar, with the alarms sending email
to the team members with the VEVENTS and VTODO and any VALARMs
being updated by the team leader. So again I can see a document
listing the pro's and con's of when to send VALARMs.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms080903010506080803060907
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTA3MTc0MjU3WjAjBgkqhkiG9w0BCQQxFgQUTp3XPxLxm46+glgGIUOe
YuqMtrYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAY7qmHd8SxVgvQsMaXPLIWkhOxuc5w2zJn0IpS3joGj2R1Dy5S4Da95nmmyK2gflS
cvJGBu38pOuKmTlc0RHODRBP9t6EBPJTRf0ncyVUsDZENcKBfYnvCgRmIBKtz6vcyKuZIcSR
N7YlurGr2ar1BDAbZVE0irevhlsOQWWkZextLEKkK30roGohHqS03dw0U6iRhv1cU4vCkQsj
YaCUp/cMlq+gK4TXSY0F57WSPIbG4oDMwmx0ETWV9irMn/r6xlcRJhRDTcZuPAqoXogCh0UI
OPLiKyBtigmDXtuh8VDlWpGZbwJ94WymEfwpzUDg6iUdm57690cPuaVKhk+uNwAAAAAAAA==
--------------ms080903010506080803060907--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i87HR2pp011590 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Tue, 7 Sep 2004 10:27:03 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i87HQqSw013963 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 7 Sep 2004 10:26:56 -0700
Message-ID: <[e-mail]>
Date: Tue, 07 Sep 2004 11:26:52 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] possible VALARM solution?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080005000900040504020100"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2004 17:27:05 -0000

This is a cryptographically signed message in MIME format.

--------------ms080005000900040504020100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



[e-mail] wrote:

> In response to both Cameron and Doug....
>
> I don't see a case for PDAs to use CAP that much - 


That was one of the CAP requirements.

And even if PDA's do not use CAP, many still use VCALENDAR objects.
And transporting the alarms is done at this time.

>
> Even if we _do_ want to use CAP, transporting VALARMS  is fraught with 
> other problems - since a PDA and sometimes other CUAs can be 
> implemented on different platforms from the CS, we have to add 
> complexity so that one end of the conversation can indicate what it 
> can/cannot do in relation to VALARMS ( "don't send me executables", "I 
> can't make sounds", and the like). 

In the client/server model - you have to transport VALARMS with CAP, 
else you have no alarms.
CAP only transports VALARMS to be used by one or more CUAs. So if CAP did
not transport them, you could not have any in your own calendar.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms080005000900040504020100
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTA3MTcyNjUyWjAjBgkqhkiG9w0BCQQxFgQUBU8wQFk/XHjPwXk0Razf
u5/dufswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAdgGENX2V1avc2iYeSgDviFbJhdE2s/HAbWB0P+s2ctPoMfGsP1Ja3cqckRrwrylR
wjN1/11MtSXfA5fpv/C2gmSW9QFqjmLj4wqHWihakJrB2avyhEvUDrLUkTSc7xC/8LV6E2dF
+ANs/aNFa+yKUnLsEGq61TWIvVk+ek+hmBCz01u54OVWpyGu87QcmfveOvIYs/vdBbElGUHv
WvWe3d5uwfEoP/1v3qV3TyKWCSMZ5c7yeqItYESFW8XRafxgEARGlLgOqeOQwaABltShgoXb
CyEAjVwSlXIxoaXwt+V1ILpCzT1sotFA+K5gnIMG06a2LnDLuHypGnjBesxBmgAAAAAAAA==
--------------ms080005000900040504020100--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i87H0Dpo009296 for <[e-mail]>; Tue, 7 Sep 2004 10:00:13 -0700
Received: from cse.ucsc.edu (adsl-63-194-88-161.dsl.snfc21.pacbell.net [63.194.88.161]) by ylpvm01.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id i87H09CY012793 for <[e-mail]>; Tue, 7 Sep 2004 13:00:09 -0400
Message-ID: <[e-mail]>
Date: Tue, 07 Sep 2004 10:00:09 -0700
From: Elias Sinderson <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] Event classes
References: <[e-mail]	p.microsoft.com>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2004 17:00:13 -0000

Doug Royer wrote:

> Great idea. New implementations will know what to do with them. RFC 
> 2445 defined the CLASS value to include 'iana-token'.
> Existing implementations should default to PUBLIC as defined in 2445 
> for CLASS when they do not understand the value.
> And we deprecate CONFIDENTIAL and PRIVATE. 

+1 - given that there is no interoperability wit respect to CONFIDENTIAL 
and PRIVATE event classes among existing implementations, they should be 
deprecated. Also, it should be noted that introducing additional event 
classes does not further the interoperability goals of the iCal 
standardization effort.

Personally, I do not feel that it is appropriate to definine access 
control mechanisms within this specification at all. Servers should 
implement and utilize existing interoperable access control mechanisms 
for iCal access. Defining new access control mechanisms for iCal 
introduces unnecessary complexity, fractures the existing specification 
landscape and takes us farther away from the stated goal of 
interoperability and standardization.


Regards,
Elias


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i87Eccpo028008 for <[e-mail]>; Tue, 7 Sep 2004 07:38:39 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc13) with SMTP id <2004090714383201600na1h1e> (Authid: TimHare); Tue, 7 Sep 2004 14:38:33 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Tue, 07 Sep 2004 10:30:48 -0400
To: [e-mail]
From: [e-mail]
Subject: RE: [Ietf-calsify] possible VALARM solution?
In-Reply-To: <[e-mail] ge.corp.microsoft.com>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2004 14:38:39 -0000

It would be desirable for the UI of a CUA to ask you, at import/open time, 
whether you want to:

         1. Ignore alarms entirely - don't set them.
         2. Import the alarms using client defaults
         3. Ask the user what kind of alarm to set, for each one imported

UIs of course, are outside of the scope of the simplification work - but 
the above 3 choices would work whether we retain the transmission of 
VALARMs, or we simplify by having a REMINDER=YES/NO parameter/property.

I've left out option 4,  Import the alarms exacly as the server sent them. 
That can only work if there is enough other complexity to determine if the 
client is a compatible platform, so it doesn't work with our goal of 
simplification.




At 09:37 AM 9/7/04, you wrote:
>Let's walk through the rest of your scenario...
>
>If you mean, importing an entire list of shared events (a published
>calendar of customer meetings) into your own calendar, or accepting a
>meeting request for that customer meeting.
>
>The meeting request is more personal, and arguably SHOULD turn on an
>alarm, but using the client's defaults - not the senders.
>
>The published calendar is more to the point.  Firing lots of past event
>alarms will not help you make the meeting, it will only cause noise that
>you will likely dismiss inadvertently to avoid the potentially many
>other pointless alarms.  Even so, this is a very small edge case of
>importing these events *just* as the event is starting.  Your CUA could
>realistically be smart enough to fire alarms for events that are also in
>process.
>
>Cameron
>
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]] On Behalf Of Doug Royer
>Sent: Monday, September 06, 2004 11:46 AM
>To: [e-mail]
>Subject: Re: [Ietf-calsify] possible VALARM solution?
>
>
> >But then, this very reasonable ask has gotten us right back where we
> >were - all VALARMS that occur in the past *should* be suppressed
> >(right?) - or else we have the less-than-desirable Netscape
> >experience... and then again, if I'm in a different building (or a
> >different time zone), I will likely want to adjust my reminders to be
> >earlier anyway.  The context of the reminder is very client-centric.
> >And once again, I find the feature dubious.
> >
> >
>I think that is a user preference. I may want to see what I forgot to go
>to when I get back late from a meeting.
>
>I would rather show up 5 minutes late to a meeting with a customer than
>not at all just because I was not running the CUA at the exact alarm
>trigger time.
>
>--
>
>Doug Royer                     |   http://INET-Consulting.com
>-------------------------------|-----------------------------
>[e-mail]                 | Office: [phone]
>http://Royer.com/People/Doug   | Fax:    [phone]
>                                | Cell:   [phone]
>
>               We Do Standards - You Need Standards
>
>
>
>_______________________________________________
>Ietf-calsify mailing list
>[e-mail]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i87DbApo021439 for <[e-mail]>; Tue, 7 Sep 2004 06:37:10 -0700
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);  Tue, 7 Sep 2004 06:37:10 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 07 Sep 2004 06:37:09 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 06:37:10 -0700
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 06:37:09 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] possible VALARM solution?
Date: Tue, 7 Sep 2004 06:37:04 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] possible VALARM solution?
thread-index: AcSUQehefq/QsddvS5W5pEvabAglPwAnQfQw
From: "Cameron Stillion" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 07 Sep 2004 13:37:09.0851 (UTC) FILETIME=[C6490AB0:01C494DF]
X-Scanned-By: MIMEDefang 2.39
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i87DbApo021439
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2004 13:37:11 -0000

Let's walk through the rest of your scenario...

If you mean, importing an entire list of shared events (a published
calendar of customer meetings) into your own calendar, or accepting a
meeting request for that customer meeting.  

The meeting request is more personal, and arguably SHOULD turn on an
alarm, but using the client's defaults - not the senders.  

The published calendar is more to the point.  Firing lots of past event
alarms will not help you make the meeting, it will only cause noise that
you will likely dismiss inadvertently to avoid the potentially many
other pointless alarms.  Even so, this is a very small edge case of
importing these events *just* as the event is starting.  Your CUA could
realistically be smart enough to fire alarms for events that are also in
process.

Cameron


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Doug Royer
Sent: Monday, September 06, 2004 11:46 AM
To: [e-mail]
Subject: Re: [Ietf-calsify] possible VALARM solution?


>But then, this very reasonable ask has gotten us right back where we 
>were - all VALARMS that occur in the past *should* be suppressed
>(right?) - or else we have the less-than-desirable Netscape 
>experience... and then again, if I'm in a different building (or a 
>different time zone), I will likely want to adjust my reminders to be 
>earlier anyway.  The context of the reminder is very client-centric.
>And once again, I find the feature dubious.
>  
>
I think that is a user preference. I may want to see what I forgot to go
to when I get back late from a meeting.

I would rather show up 5 minutes late to a meeting with a customer than
not at all just because I was not running the CUA at the exact alarm
trigger time.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards





X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8729jpo007429 for <[e-mail]>; Mon, 6 Sep 2004 19:09:46 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc11) with SMTP id <2004090702094001300ar08ae> (Authid: TimHare); Tue, 7 Sep 2004 02:09:40 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Mon, 06 Sep 2004 22:01:53 -0400
To: [e-mail]
From: [e-mail]
Subject: RE: [Ietf-calsify] possible VALARM solution?
In-Reply-To: <[e-mail] ge.corp.microsoft.com>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2004 02:09:46 -0000

In response to both Cameron and Doug....

I don't see a case for PDAs to use CAP that much - they either seem to be 
their own Calendar Service (i.e. the user uses _only_ the PDA for 
calendaring), or they are an adjunct to the desktop CUA and the 
communication between PDA and desktop is more in the realm of SyncML. I 
could be wrong on this point, but that's how I see it.

Even if we _do_ want to use CAP, transporting VALARMS  is fraught with 
other problems - since a PDA and sometimes other CUAs can be implemented on 
different platforms from the CS, we have to add complexity so that one end 
of the conversation can indicate what it can/cannot do in relation to 
VALARMS ( "don't send me executables", "I can't make sounds", and the like).

So, while I don't necessarily think that transporting alarms is a good 
idea,   I think that transporting the need for an alarm is probably the 
best simplification we could come up with.


Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i86IkWpp024575 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 6 Sep 2004 11:46:33 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i86IkMSw028719 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 6 Sep 2004 11:46:23 -0700
Message-ID: <[e-mail]>
Date: Mon, 06 Sep 2004 12:46:22 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] possible VALARM solution?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000303000305050008040902"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2004 18:46:34 -0000

This is a cryptographically signed message in MIME format.

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


>But then, this very reasonable ask has gotten us right back where we
>were - all VALARMS that occur in the past *should* be suppressed
>(right?) - or else we have the less-than-desirable Netscape
>experience... and then again, if I'm in a different building (or a
>different time zone), I will likely want to adjust my reminders to be
>earlier anyway.  The context of the reminder is very client-centric.
>And once again, I find the feature dubious.
>  
>
I think that is a user preference. I may want to see what I forgot to go to
when I get back late from a meeting.

I would rather show up 5 minutes late to a meeting with a customer
than not at all just because I was not running the CUA at the exact
alarm trigger time.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms000303000305050008040902
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTA2MTg0NjIyWjAjBgkqhkiG9w0BCQQxFgQUUFEzkX7YQxKHwBqgo7H0
LAusKGYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAJk0b+hE/KrNbaZvqsS+BkHx9ECxnzfUW5ndrhs4CQmCyn0yQoIpaJ1IprmyBQFE4
3bshVobxIcyivJuCq/Xq704rNCnGtNGH+JfU8dfKuZ5YfDJ+xNuBOB+PajO+0pT/tVcUKiAz
k8ZnVmtfcgY8JEpQKcO44VF+1Rzh6hbxyIouSI3lglWuW/lZAkjKz2oklaAPUEv8lqncIhAX
ubBiUYHVDLkbWEnUnj+DSki6x05I8hxf9OLd8WMzD+CWXMwXOerFn7HNhhws8cEx2sCqnekt
3+sshvYZtQOfq9rGy0SrXzShZCDxEYWAgMuwmD3VGdrN8U0/EHX8BScGDs9gfwAAAAAAAA==
--------------ms000303000305050008040902--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i86IgMpp024462 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 6 Sep 2004 11:42:23 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i86IgDSw028651 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 6 Sep 2004 11:42:15 -0700
Message-ID: <[e-mail]>
Date: Mon, 06 Sep 2004 12:42:13 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] possible VALARM solution?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020909070107090402080207"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2004 18:42:25 -0000

This is a cryptographically signed message in MIME format.

--------------ms020909070107090402080207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


CAP adds the LOCAL parameter (boolean) to indicate if a VALARM
is to be local to the CS. They exist so that a CU can add VALARMs
that only they see. These VALARMs are never transported to
other CUs (however they may be transported to other CUAs or CSs.)

If I have a local VALARM on my desktop, I DO want it transported
to my PDA. however not when I transport the appointment
to a 2nd or 3rd party.

So VALARM do need to be able to be transported across vendor
implementations.


[e-mail] wrote:

> Here's an idea for simplification of the "VALARM problem".
>
> The originator of a calendar object (meeting, to-do item, appointment) 
> may desire that someone be reminded of such an event, which I feel is 
> a valid option to have - if I schedule a staff meeting on a regular 
> schedule, far in advance, I might like to indicate that all employees 
> be reminded of it on that day. However, as many have pointed out, the 
> methods of notification should be part of the UI.  My proposal for 
> simplification, then, is that each component have a simple, binary 
> property, or a parameter of the component, which is a YES/NO value for 
> 'remind the attendee/originator of this object'.  If that property is 
> set to YES, then the UI is responsible for asking the UI owner how 
> they want to be reminded about that object.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms020909070107090402080207
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTA2MTg0MjEzWjAjBgkqhkiG9w0BCQQxFgQUAXwbBJR5WVSghAaJVXqN
jVtXnSQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAKfctap4F7gqgm2+hfV13zm7d6hIKkZl43UlBf3v+oL7MmP5dkmEhMBRafIB7l1dw
sP2J54Az4Yfxt9A4VOLvpTFqs5K0D1uvk5YZj7p84akxrVtLfGdFYKMSiUlXkjrS6C5Yp5k9
0iJtWjyEZkOfFA3WIzm5X/2HAbT13rrRFQLpK+2etvwISGJ9AR0kF0O4b+yOec8prLxvaPt/
ETJlhthWnSNIICHDDMMInjpliKWvTvp221sM2vop4z4hRXeLpL8Ea2JXAXIDnLzLEr6ywA9W
NUBiAMynajV9iykWlrmw9uniC4E4Oo1007Uewbw2bZnt9/E7Xa1kLGajeouroAAAAAAAAA==
--------------ms020909070107090402080207--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i86IULpp024069 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 6 Sep 2004 11:30:22 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i86IUBSw028527 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 6 Sep 2004 11:30:14 -0700
Message-ID: <[e-mail]>
Date: Mon, 06 Sep 2004 12:30:10 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] Event classes
References: <[e-mail]	p.microsoft.com>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020400060000020305010909"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2004 18:30:24 -0000

This is a cryptographically signed message in MIME format.

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


Great idea. New implementations will know what to do with them.
RFC 2445 defined the CLASS value to include 'iana-token'.

Existing implementations should default to PUBLIC as defined in 2445
for CLASS when they do not understand the value.

And we deprecate CONFIDENTIAL and PRIVATE.

>
> OWNERONLY - as per your definition (2)
> DELEGATES - as per your definition (3) 



-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms020400060000020305010909
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTA2MTgzMDEwWjAjBgkqhkiG9w0BCQQxFgQUYZVGiPyeyY2K1A3Vk3fS
iLRhmvkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAroofjfh7S/6CmJzxrnZPw9ego5yQeHaLf0maN68kRiUSQ8JfwluulA94ezNPCjZG
jFoMlde5lri+HU5Qf0b9kONNm4dL5mguc+PuXDvlRPPfz3zeRHjzWXnuQShwbk0q0mAaZiYL
2ep290kBQYw82GSusvD/UtBSqxG7hhZHbivPrcgTb+aXk8knvyqPFUGJHnSTGNvOQlSCgSh3
OrQt0eLItVAPk5g+FPWom7ekVZwFxUl0Lzs5W53X305xwk/Dm2gvZRTMZQpJ+RLqkE39WrPK
dVVgwiin/9wrWvP+U94jxhWMZIRWpPdqwpkm2LeWGJ1YpV8pmxVdmWcp+zw7dAAAAAAAAA==
--------------ms020400060000020305010909--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i863lNpo016333 for <[e-mail]>; Sun, 5 Sep 2004 20:47:23 -0700
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);  Sun, 5 Sep 2004 20:47:23 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 05 Sep 2004 20:47:23 -0700
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 5 Sep 2004 20:47:25 -0700
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Sep 2004 20:47:23 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] possible VALARM solution?
Date: Sun, 5 Sep 2004 20:47:17 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] possible VALARM solution?
thread-index: AcSTum5hFhlJl2sWQV6oGvwGLQhETwACJnhw
From: "Cameron Stillion" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 06 Sep 2004 03:47:23.0068 (UTC) FILETIME=[37B4B7C0:01C493C4]
X-Scanned-By: MIMEDefang 2.39
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i863lNpo016333
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2004 03:47:24 -0000

I think having a sender-defined suggested reminder is a reasonable
feature, though I do not find it all that compelling.  Assuming we agree
that the standard should address this particular feature, I just want to
point out that the UI could also decide not to bother the poor user who
might easily be importing ALL 27 of his team's recurring events for the
lifetime of the product cycle (since he is just joining the team, for
instance).  We must think about these features in terms of scale.

But then, this very reasonable ask has gotten us right back where we
were - all VALARMS that occur in the past *should* be suppressed
(right?) - or else we have the less-than-desirable Netscape
experience... and then again, if I'm in a different building (or a
different time zone), I will likely want to adjust my reminders to be
earlier anyway.  The context of the reminder is very client-centric.
And once again, I find the feature dubious.


Cameron


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Sunday, September 05, 2004 7:28 PM
To: [e-mail]
Subject: [Ietf-calsify] possible VALARM solution?

Here's an idea for simplification of the "VALARM problem".

The originator of a calendar object (meeting, to-do item, appointment)
may desire that someone be reminded of such an event, which I feel is a
valid option to have - if I schedule a staff meeting on a regular
schedule, far in advance, I might like to indicate that all employees be
reminded of it on that day. However, as many have pointed out, the
methods of notification should be part of the UI.  My proposal for
simplification, then, is that each component have a simple, binary
property, or a parameter of the component, which is a YES/NO value for
'remind the attendee/originator of this object'.  If that property is
set to YES, then the UI is responsible for asking the UI owner how they
want to be reminded about that object.

Comments?

Tim Hare
Interested Bystander, Non-Inc. 


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i863Zqpo016051 for <[e-mail]>; Sun, 5 Sep 2004 20:35:52 -0700
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);  Sun, 5 Sep 2004 20:35:52 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 05 Sep 2004 20:35:52 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 5 Sep 2004 20:35:54 -0700
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Sep 2004 20:35:54 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] Event classes
Date: Sun, 5 Sep 2004 20:35:43 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] Event classes
thread-index: AcSTnvJeSHEebur+TiugyW95U0df2AAIRXvg
From: "Cameron Stillion" <[e-mail]>
To: "Cyrus Daboo" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 06 Sep 2004 03:35:54.0252 (UTC) FILETIME=[9D23BCC0:01C493C2]
X-Scanned-By: MIMEDefang 2.39
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i863Zqpo016051
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2004 03:35:53 -0000

This is similar to the TRANSP problem - we have existing values that
don't quite match implementations and that are quite difficult to grasp.
We need better values to clarify, but we also want existing software to
not have to be rewritten.

PUBLIC is clearly understood and wants no clarification.  PRIVATE and
CONFIDENTIAL mean different things to different implementations - but
this is the whole reason why iCal is not yet a standard.  This is
EXACTLY why calsify exists!  Let us bring to bear the collective brains
of this forum to define these in a way that CAN make sense and that we
can call STANDARD.  All previous implementations will be struggling
anyway to interop, and it is very clear why.

Personally, I tend toward the three visibility labels also in use in
modern computer programming languages: 
	PUBLIC - visible to all
	PROTECTED - visible to me and a few other special entities
	PRIVATE - visible only to me

Various flavors of protected could be concocted, leading to the FRIEND
list and other client-specific notions, but the tag would suffice.  In
all honesty, I don't care if protected is named "CONFIDENTIAL", but I
find it clearer as it is stated above.  Maybe it's because I'm a
programmer, but isn't that really our audience here?

I think we can come to a fairly quick resolution on the names of these
values - but I think there is a more important question afoot.  When do
we transport these properties?  This comes back to the various reasons
we use iCal...

As usual, all these properties make sense to store and transport when
iCal is used by an individual to access their own store.  When I publish
a calendar to a "public" recipient, the answer is moot.  

But What about a private (or other *protected* flavor)? Do the events
reflect their initial visibility? Can the recipient tell if they can see
an appointment because they are special?  Even more interesting is the
meeting request/response case - perhaps an event is private to me
because of the nature of the meeting (e.g. legal consultation) so I mark
it as such.  Obviously the recipient of the request would also see the
event, but may or may not consider it the same level of visibility.  

I would suggest that shared data is always public as far as the
recipient is concerned, especially since the nature of this property is
explicitly NOT to enforce access or visibility but merely to suggest
ways the CUA / CS can avoid doing the wrong thing.  Also, because of
this nature, once data leaves the comfort of its home and goes across
the wire to another client, all bets are off.  Only crypto will solve
that problem, and that is beyond the scope of this property and this
standard.


cameron


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Cyrus Daboo
Sent: Sunday, September 05, 2004 4:20 PM
To: [e-mail]; [e-mail]
Subject: Re: [Ietf-calsify] Event classes

Hi Tim,

--On Sunday, September 5, 2004 4:45 PM -0400 [e-mail] wrote:

>          1. PUBLIC - anyone can read this item and see the details
>          2. PRIVATE- only myself and people I delegate can see the 
> details, others can see that time is blocked
>          3. CONFIDENTIAL- only I can see the details, others can see 
> that time is blocked

Your interpretation of PRIVATE & CONFIDENTIAL is not what others have. 
Personally I thought of those in the same way you do, however I found
out that some implementations treat them the other way around (i.e.
PRIVATE is owner only, CONFIDENTIAL is owner + delegates). So it may
well be that the current PRIVATE and CONFIDENTIAL values cannot be
explicitly defined in an interoperable way, and we may need new values,
e.g.:

OWNERONLY - as per your definition (2)
DELEGATES - as per your definition (3)

I don't think there is an issue with PUBLIC.

--
Cyrus Daboo
_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i862Zrpo014397 for <[e-mail]>; Sun, 5 Sep 2004 19:35:53 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc12) with SMTP id <20040906023547014002hnsie> (Authid: TimHare); Mon, 6 Sep 2004 02:35:48 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Sun, 05 Sep 2004 22:28:15 -0400
To: [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] possible VALARM solution?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2004 02:35:53 -0000

Here's an idea for simplification of the "VALARM problem".

The originator of a calendar object (meeting, to-do item, appointment) may 
desire that someone be reminded of such an event, which I feel is a valid 
option to have - if I schedule a staff meeting on a regular schedule, far 
in advance, I might like to indicate that all employees be reminded of it 
on that day. However, as many have pointed out, the methods of notification 
should be part of the UI.  My proposal for simplification, then, is that 
each component have a simple, binary property, or a parameter of the 
component, which is a YES/NO value for 'remind the attendee/originator of 
this object'.  If that property is set to YES, then the UI is responsible 
for asking the UI owner how they want to be reminded about that object.

Comments?

Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i862TOpo014150 for <[e-mail]>; Sun, 5 Sep 2004 19:29:24 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc12) with SMTP id <20040906022918014002aknie> (Authid: TimHare); Mon, 6 Sep 2004 02:29:18 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Sun, 05 Sep 2004 22:21:34 -0400
To: [e-mail]
From: [e-mail]
Subject: Re: [Ietf-calsify] transport format as subset of interactive format?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2004 02:29:24 -0000

iTIP was the "transport-independent" format, and iCalendar was the format 
for the calendar objects - I think these two concepts are useful. I do 
think, however, that we are having serious problems trying to add outer 
layers to this (and I do think layered approaches work well, usually). In 
traditonal layered "things", each outer layer provides an envelope, and 
doesn't really care what the contents of the envelope are. In calendaring, 
however, it's hard to add an outer layer to exchange calendar objects, 
without reference to the objects - for example, you can't easily have a 
protocol layer for scheduling a meeting without the dates and times being 
exposed to that layer of the protocol.

I think that the interactive protocol (CAP) is _intended_  to be an outer 
layer for iTIP, but it does add a lot of new components, properties, and or 
values - and therefore a lot of complexity. I think that it's useful to 
consider how these all should relate - and perhaps IF we can layer these, 
rework things into layers. To that end, I would propose that we take the 
major elements list (and many thanks for the HTML table, by the way) and 
try to add two things to each element:

         A. What "protocol layer" the element has to be part of, if 
any,  using three(?) layers of iCalendar, iTIP, and the application layer
         B. What "level" the element has to be part of - level 0 being the 
most basic interoperability layer
             (and I guess we ought to define how many levels and what they are)


At 11:26 AM 8/30/04, Nathaniel Borenstein wrote:
>It's starting to sound to me like the transport format should be a 
>*subset* of the interactive access format.  Is that a useful thing to 
>consider in simplifying the documents?  -- Nathaniel
>
>On Aug 29, 2004, at 10:47 PM, Bernard Desruisseaux wrote:
>
>>Cameron Stillion wrote:
>>
>>>I would like to suggest the removal of VALARM from the iCal spec.
>>>  I have yet to hear or come up with a good scenario that includes sending
>>>alarm information from one client to another.
>>
>>Cameron,
>>
>>Here's a good scenario:
>>
>>1- I'm invited to a meeting.
>>
>>2- I synchronize my SyncML device.
>>
>>3- Since the calendar server knows that I want reminders
>>    with a 10 minutes lead time, the VEVENT uploaded to
>>    my SyncML device will contain a VALARM specifying an
>>    alarm 10 minutes prior the VEVENT start time.
>>
>>Don't ask me for a good scenario in the context of iTIP.
>>In my opinion, VALARM should not be used in the context
>>of iTIP. If you receive an iTIP message with a VALARM
>>just ignore it.
>>
>>Cheers,
>>Bernard
>>
>>_______________________________________________
>>Ietf-calsify mailing list
>>[e-mail]
>>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>
>
>_______________________________________________
>Ietf-calsify mailing list
>[e-mail]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i85NK3pp008707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 5 Sep 2004 16:20:04 -0700
Received: from [10.0.1.3] (pool-141-158-116-239.pitt.east.verizon.net [141.158.116.239]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i85N16o3032695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Sep 2004 19:01:11 -0400
Date: Sun, 05 Sep 2004 19:19:54 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: [Ietf-calsify] Event classes
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail] p.microsoft.com>	<[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Scanned-By: MIMEDefang 2.39
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 05 Sep 2004 23:20:04 -0000

Hi Tim,

--On Sunday, September 5, 2004 4:45 PM -0400 [e-mail] wrote:

>          1. PUBLIC - anyone can read this item and see the details
>          2. PRIVATE- only myself and people I delegate can see the
> details, others can see that time is blocked
>          3. CONFIDENTIAL- only I can see the details, others can see that
> time is blocked

Your interpretation of PRIVATE & CONFIDENTIAL is not what others have. 
Personally I thought of those in the same way you do, however I found out 
that some implementations treat them the other way around (i.e. PRIVATE is 
owner only, CONFIDENTIAL is owner + delegates). So it may well be that the 
current PRIVATE and CONFIDENTIAL values cannot be explicitly defined in an 
interoperable way, and we may need new values, e.g.:

OWNERONLY - as per your definition (2)
DELEGATES - as per your definition (3)

I don't think there is an issue with PUBLIC.

-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i85KrSpo030923 for <[e-mail]>; Sun, 5 Sep 2004 13:53:29 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc11) with SMTP id <2004090520532301300ar489e> (Authid: TimHare); Sun, 5 Sep 2004 20:53:23 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Sun, 05 Sep 2004 16:45:37 -0400
To: [e-mail]
From: [e-mail]
Subject: Re: [Ietf-calsify] Event classes
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 05 Sep 2004 20:53:29 -0000

In my opinion, there are two things to be done regarding CLASS:

         1. Define the meaning of the three values explicitly
         2. Let implementations handle the values

I'm not going to read the spec here, I'm going to reason from past 
experience (a mainframe calendaring product-that-was-not-PROFS) and say 
good definitions for the three values are:

         1. PUBLIC - anyone can read this item and see the details
         2. PRIVATE- only myself and people I delegate can see the details, 
others can see that time is blocked
         3. CONFIDENTIAL- only I can see the details, others can see that 
time is blocked

Use cases:
         1. PUBLIC - a meeting on my schedule
         2. PRIVATE- an appointment regarding contract negotiations on my 
schedule
         3. CONFIDENTIAL- an appointment for a medical screening

To me, the idea of CLASS is to indicate roughly how this item should be 
handled;  the implementation can use whatever mechanisms that they would 
like to provide this handling. There is no guarantee that a particular 
implementation will handle CONFIDENTIAL or PRIVATE correctly - but then, 
the market should take care of those cases, no? Or the legal system after 
Joe Users' CONFIDENTIAL appointment with his mistress is revealed to the 
PUBLIC (i.e.  Mrs. User!).






Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i83F9Kpo029032 for <[e-mail]>; Fri, 3 Sep 2004 08:09:20 -0700
To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 3 Sep 2004 11:09:46 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 09/03/2004 11:06:21 AM, Serialize complete at 09/03/2004 11:06:21 AM
Content-Type: multipart/alternative; boundary="=_alternative 005320FD85256F04_="
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] rfc 2445 VTimeZone document clarificatioin
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Sep 2004 15:09:20 -0000

This is a multi-part message in MIME format...

--=_alternative 005320FD85256F04_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

4.6.5 Time Zone Component
....

   The "VTIMEZONE" calendar component MUST be present if the iCalendar
   object contains an RRULE that generates dates on both sides of a time
   zone shift (e.g. both in Standard Time and Daylight Saving Time)
   unless the iCalendar object intends to convey a floating time (See
   the section "4.1.10.11 Time" for proper interpretation of floating
   time). It can be present if the iCalendar object does not contain
   such a RRULE. In addition, if a RRULE is present, there MUST be valid
   time zone information for all recurrence instances.


The last line "

In addition, if a RRULE is present, there MUST be valid
   time zone information for all recurrence instances."

should be removed. 
The description above that line is complete.  The last line only adds 
confusion about floating times.
Floating times are events such as I run from 8am to 9am no mater where I 
am.



--=_alternative 005320FD85256F04_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i82K3rpo027737 for <[e-mail]>; Thu, 2 Sep 2004 13:03:57 -0700
In-Reply-To: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 2 Sep 2004 16:03:52 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 09/02/2004 04:03:57 PM, Serialize complete at 09/02/2004 04:03:57 PM
Content-Type: multipart/alternative; boundary="=_alternative 006E37CF85256F03_="
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] Interop results
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Sep 2004 20:03:58 -0000

This is a multi-part message in MIME format...

--=_alternative 006E37CF85256F03_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

I wanted to give the list a status update on the interop results.  I am 
waiting on a reply back from one of the participants of the interop.  They 
expect to have the results back to me within two weeks. They got caught up 
in "work" (surprise - don't we all) and they are traveling to boot.

I have enough details that I can post what is working/not working, (based 
on all 4 interops) but if I include their last minute details we have a 
bunch more data.  I'd like to include that information because it relates 
to TODO's. 

I'll post another status update early next week.
--=_alternative 006E37CF85256F03_=--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mid-2.inet.it (mid-2.inet.it [213.92.5.19]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8272mpo032203 for <[e-mail]>; Thu, 2 Sep 2004 00:02:49 -0700
Received: from hhazewinkel.inet.it [::ffff:213.92.1.191] by mid-2.inet.it via I-SMTP-5.1.13-51A id ::ffff:213.92.1.191+xPepDiT0t1gx; Thu, 02 Sep 2004 09:02:44 +0200
Message-ID: <[e-mail]>
Date: Thu, 02 Sep 2004 09:02:43 +0200
From: Harrie Hazewinkel <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Event class
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.39
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Sep 2004 07:02:50 -0000

Bernard Desruisseaux wrote:
> Harrie Hazewinkel wrote:
>> Bernard Desruisseaux wrote:
> 
> Would you mind sharing your custom properties?

It are 2 properties.

First property is telling the application if the user is the owner
  (that way we allow all operations).
Second property is telling the application which operation he may
do, invite/respond.

Maybe some duplication you have, but we also choose
a simple ACL mechanism handled by the application.
The server is more strict, but we believed it would not make
sense to provide to much ACL details to a user.


cheers,
Harrie



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i81NFHpp003873 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Wed, 1 Sep 2004 16:15:18 -0700
Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i81NF4Md019246 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 1 Sep 2004 16:15:06 -0700
Message-ID: <[e-mail]>
Date: Wed, 01 Sep 2004 17:15:03 -0600
From: Doug Royer <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: All the ways we use iCal  (was:  [Ietf-calsify] Event class)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050508010206090406020606"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Sep 2004 23:15:19 -0000

This is a cryptographically signed message in MIME format.

--------------ms050508010206090406020606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Cameron Stillion wrote:

>That is a great clarification of the EVENT CLASS problem.
>
>To answer the question - I am not building a CS, I'm building a CUA that
>talks to other CUAs, and I am in complete control of my Private and/or
>Confidential access lists.  But I see your point.
>  
>
'CS' is defined in iTIP to mean the other end of the connection when a CUA
is getting data from a CUA (such as iMIP) . CAP had not yet been invented.

The 'S' stands for SERVICE not server in iTIP.

The issue is can one vendor talk with another vendors data
in a way that everyone knows what to do with the data. It seems
to me the answer is "no" with respect to the CLASS property.

So again I think that the idea may be good if defined in an unambiguous
way. However there is no way to use the same name (CLASS) and
tell which (old or new) usage of the CLASS property is intended. I think
we need to deprecate CLASS and define CLASS2 . Then clearly
define CLASS2.

>And now that you mention it, I see that there are really three purposes
>that we are trying to use iCal for:
>
>1) Native file format for storage of calendars
>     [ I suppose this could be client or server. ]
>
agree.

>2) Transport format for exchanging calendars between users or CUAs
>	[ rich client model where server-involvement 
>	  is not required or even necessarily desired.
> 	  Business Logic is implemented on the client. ]
>
At  this level it looks to me as if not all vendors use the same meaning
of the CLASS value. Plus some transport the CLASS property, others do not.
This means that it is not an interoperable property - correct?

>3) Transport format for sending calendar data either:
>	from CS to CS, or from CS to CUA
>	[ thin client model where server-involvement
>	  is required, and business logic is implemented there. ]
>
>  
>
The transfer of data between a CUA and CAP-CS is an extension of 
transport (iTIP)
Not a replacement. So the same problem exists as in (2) above.

There is no CS to CS protocol defined yet.

And the business logic can be in the CS and CUA. It depends on the usage
of the calendar information and application.  Access control is in a 
CAP-CS - yes.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards



--------------ms050508010206090406020606
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw
MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi
FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb
MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg
X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE
1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91
OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4
X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz
ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE
aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9
jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs
VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4
r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y
SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy
HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq
UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn
WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X
ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQwOTAxMjMxNTAzWjAjBgkqhkiG9w0BCQQxFgQULqjvjFyQi/ys2t/R5IeD
ytWoL7UwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD
fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB
BQAEggEAhEtmofV36FiLv5a6J2fUbPvAufI8gsj3JfEVgVuHUTkg1rduGsRasp2pVHJaT5+6
YvIQbasnZjZWRa7WgTewfN59fz2jhSANXBgOPqjENSMzLAOwNBWcYH1MfcMQRkVaS34htAlU
39OFzdyk7k7LFqxRnQJezxXlBTh4t9Htu0T86VjV7/cCQgwK2EEFTna96k06xywZkHzTCaZB
i8ppKEmzS0XwoOwNwdeRla6jw6LODLhX0JXWXWOu0NMvDx03m/dM6Px0OkxUHIenVmqdey+T
JVw2KMtJHOFn8CO8AIF0h80ojsRuZARlXS0OhLunvlAeLr99ynl5BuU5yj+WqQAAAAAAAA==
--------------ms050508010206090406020606--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i81JJ0po003786 for <[e-mail]>; Wed, 1 Sep 2004 12:19:03 -0700
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);  Wed, 1 Sep 2004 12:19:00 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Sep 2004 12:19:00 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Sep 2004 12:19:05 -0700
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Sep 2004 12:18:59 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: All the ways we use iCal  (was:  [Ietf-calsify] Event class)
Date: Wed, 1 Sep 2004 12:18:58 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: All the ways we use iCal  (was:  [Ietf-calsify] Event class)
thread-index: AcSPfRL8w0uWgxCdQsacQi9OV6ud2AAG3Yrw
From: "Cameron Stillion" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 01 Sep 2004 19:18:59.0177 (UTC) FILETIME=[88515590:01C49058]
X-Scanned-By: MIMEDefang 2.39
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i81JJ0po003786
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Sep 2004 19:19:04 -0000

That is a great clarification of the EVENT CLASS problem.

To answer the question - I am not building a CS, I'm building a CUA that
talks to other CUAs, and I am in complete control of my Private and/or
Confidential access lists.  But I see your point.

And now that you mention it, I see that there are really three purposes
that we are trying to use iCal for:

1) Native file format for storage of calendars
     [ I suppose this could be client or server. ]
2) Transport format for exchanging calendars between users or CUAs
	[ rich client model where server-involvement 
	  is not required or even necessarily desired.
 	  Business Logic is implemented on the client. ]
3) Transport format for sending calendar data either:
	from CS to CS, or from CS to CUA
	[ thin client model where server-involvement
	  is required, and business logic is implemented there. ]


Looking at it this way, it seems that these three purposes are likely to
have slightly different needs, and it does seem that many of our
discussions get hung up on these differing purposes.

Is it possible to remove any of these purposes from our intention of
what iCal *should* be? Doug and Nathaniel have each mentioned at one
time or another that we should focus on the transport perspective, and
not the storage format. I also wonder if perspective #2 and #3 should be
considered separately - or one as a subset of the other...

Would it make sense to focus on these one at a time, or to differentiate
the support for specific properties based on these three dimensions?  I
realize I'm asking a broader question about the way we approach
resolving our differences surrounding the collective iCal standards -
but maybe we can move forward more easily with this kind of approach.


cameron


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Doug Royer
Sent: Tuesday, August 31, 2004 10:07 AM
To: [e-mail]
Subject: Re: [Ietf-calsify] Event class


>...
>In fact, I would expect that when a calendar is published or sent via 
>e-mail, my client had better exclude the events marked as PRIVATE or 
>CONFIDENTIAL (modulo some sort of override...)  It would be 
>unacceptable to include them and simply mark them as such.  Perhaps 
>this is another case of a property that should almost never be sent, 
>but that may be stored.
>
>  
>

I agree with both points. And the fact that  it is undefined and the
implementation specifics are disputed is the point. Patrice's
explanation is not consistent with yours. So would his CUA accessing
your CS give away your CONFIDENTIAL data?  It looks like yes as long as
who he wanted to iMIP it to, was in his trusted list.

Is the idea of CLASS useful - yes.
Is their consistent and interoperable usage of the CLASS property - no.

CLASS needs to be re-done in a way that new CUA's and CS's know exactly
what is expected, which (CUA or CS) is to enforce the access control.
And when to set it, forward it, or deny access to it.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards