Subject: W-25 Remove MUST from UID in 4.8.4.7

From: Doug Royer <[email-masked]>
Date: Tue, 17 Aug 1999 15:29:49 -0700 (PDT)

W-25 Remove MUST from UID in 4.8.4.7           U

I did not see any objections to this - change it to a 'Y' ?

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: [email-masked] (Robert Weiler)
Date: Tue, 17 Aug 1999 16:27:29 -0700 (PDT)

> I did not see any objections to this - change it to a 'Y' ?

I object to this change. Requiring the UID strikes me as harmless, whereas the 
lack of a UID strikes me as a significant loss of utility. If I have the UID, I 
know where the VEVENT came from, without it, I'm never sure.

In the absence of a compelling argument that this causes a problem, I'd say 
leave it alone.

Bob Weiler
Amplitude Software

---

From: Doug Royer <[email-masked]>
Date: Wed, 18 Aug 1999 08:17:58 -0700 (PDT)

> Date: Tue, 17 Aug 1999 16:27:29 -0700 (PDT)
> From: [email-masked] (Robert Weiler)
> 
> 

A fetch from a CS via CAP can result in a VEVENT without a UID.
It *is* valid not to have a UID in a VEVENT in CAP. 

The iTIP restriction tables mandate UID while using iTIP methods.

By removing it from iCalendar, it allows CAP to fetch some
of the details of an event without having to include UID.

By leaving it in, it makes CAP break iCalendar. 

-Doug

---

From: [email-masked]
Date: Wed, 18 Aug 1999 15:54:19 GMT

This is a request to remove the "MUST be a globally unique identifier", 
not merely remove the word "MUST" from section 4.8.4.7 of iCalendar.
We should be clearer in our issues log description and also which 
RFC/document is effected by the proposed change/issue.
I am against changing this. The intent is that the UID _are_ unique. If 
for some reason they are not, then we should view this as an exception 
rather than a normal condition.
NO...Let's keep the words "MUST be a globally unique identifier" in the 
definition for UID.
-- Frank

---

From: [email-masked] (Robert Weiler)
Date: Wed, 18 Aug 1999 09:42:57 -0700 (PDT)

Thanks for the clarification Doug. That being the case, I'd prefer to change iCalendar to 
require the UID, but your are right that the important thing is that the specifications 
agree.

Bob Weiler

> Date: Wed, 18 Aug 1999 08:17:58 -0700 (PDT)
> From: Doug Royer <[email-masked]>
> Subject: Re: W-25 Remove MUST from UID in 4.8.4.7
> To: [email-masked]
> MIME-Version: 1.0
> Content-MD5: l/Wa3+Sr2EWwebNQXgQaRA==
> List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
> List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
> 
> 

Robert Weiler
Amplitude Software Corporation
415-659-3520

---

From: [email-masked]
Date: Wed, 18 Aug 1999 17:16:50 GMT

Doug:
So, I had this wrong. Sorry. What you want to change is:
   Conformance: The property MUST be specified in the "VEVENT", "VTODO",
   "VJOURNAL" or "VFREEBUSY" calendar components.

To read that the "property can be specified...". Right? Leave it to iTIP 
to specify what the restriction tables are?

-- Frank

---

From: Doug Royer <[email-masked]>
Date: Wed, 18 Aug 1999 10:21:47 -0700 (PDT)

> From: [email-masked]
> Date: Wed, 18 Aug 1999 17:16:50 GMT
> 
> Doug:

Yep :-)

I think with the email from Rob the ends any objections?

If so I'll change the status next week and add a new (I) action item.

-Doug

---

From: [email-masked]
Date: Wed, 18 Aug 1999 19:40:19 GMT

Ok List. Agree that this ends objections on W-25 ? Electronic hums?

Doug Royer <[email-masked]>
Sent by: [email-masked]
08/18/99 01:21 PM
Please respond to ietf-calendar

        cc: 

Yep :-)

-Doug
Mountain View, CA 94040                          Ham Radio: N6AAW, 
Aviation: PP-ASEL

---

From: [email-masked]
Date: Mon, 23 Aug 1999 10:38:00 -0400

Pat asked for:
>Agree that this ends objections on W-25 ?

Not to be a fly in the CAP ointment but I have a concern Id like to make 
sure is unfounded or will be addressed by any new action items.

Since UID has been the key to referencing entries so far (UID then UID and 
RECURRENCE-ID), if a vEvent can be generated w/o a UID then a VERSION:2.0 
iCalendar client will choke since it expects to find it.   This then begs 
the question "Should VERSION be rev'd to be 3.0;3.0 for iCalendar entries 
that have no UID?".   Perhaps not since the ABNF allows it to NOT be there 
and the ABNF overrules the prose....   (Perhaps I just need more caffine 
on Monday AMs before catching up on list traffic!)

If not, then any existing iCalendar engine will fail to grok it.  If so, 
the ramifications are pretty big; no existing engine can  safely assume 
that it can accurately parse and understand the entry.

Im fine w/making the proposed change to 4.8.4.7 if we also add the 
following text (or close facimile) to the start of Description: under the 
same section: "This calendar property is required to uniquely identify and 
reference a calendar compoent in a calendar or calendar store."  The 
intent being that readers are made fully aware that UID should be used 
when trying to reference nearly all components in a CS, not some funky 
search filter or other obtuse means. 

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Tue, 24 Aug 1999 17:00:30 GMT

Alex:
Just to be clear. It is NOT "MAY" but rather "can". That is in a given
iCalendar object you "can" have a UID.

-- Frank

---

From: Doug Royer <[email-masked]>
Date: Wed, 25 Aug 1999 10:32:58 -0700 (PDT)

> Date: Tue, 24 Aug 1999 15:34:04 GMT
> 
> Doug:
> I disagree that we should just remove the MUST from the UID section in 
> iCalendar. This may be hair-splitting, but rather than just remove the 
> MUST, we need to change it to "can". The UID can be present. In addition, 
> we need to add the following so that we don't look the intent of the 
> original iCalendar contribution.

I agree, 'can' is appropriate.

> "The UID property is required in iCalendar objects that wish to identify a 
> particular  calendar component in a calendar store. Unambiguous 
> identification of particular calendar component may also include reference 
> to the SEQUENCE, RECURRENCE-ID and DTSTAMP properties."
> The purpose of UID is to differentiate one calendar component from 
> another. I agree that in some cases, such as when retrieving arbitrary 
> calendar information, you may not need the UID in the iCalendar object. 
> However, this does not remove the need to make sure that this section in 
> the iCalendar standard clarifies the role of this property.

True. I just wanted to make sure that we did not have to put
one in just because iCalendar said it MUST be there (all of the time).

>>> DOES ANYONE DISAGREE ???????

If not next week I'll change the status to 'Y'.

-Doug