Subject: CAP: why do we need GENERATEUID?

From: John Stracke <[email-masked]>
Date: Thu, 16 Aug 2001 14:34:43 -0400

GENERATEUID asks the CS to generate one or more unique UIDs. What is 
this for? Why can't the client create its own UIDs, like any other CUA? 
Why should we introduce extra round-trips, and extra work on the CS?

If there's some strong reason the UID has to be generated by the CS, 
then it should still not be done in a separate command; CREATE should 
accept components without UIDs, and report back the UIDs they were assigned.

-- 
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"Baldric, how did you manage to find a turnip|
[email-masked] <mailto:[email-masked]>|that cost 400,000 pounds?" "Well, I had to   |
|                |haggle." --Blackadder III                    |
\==============================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Mon, 20 Aug 2001 16:49:04 -0500

> Why should we introduce extra round-trips, and extra work on the CS?

My interpretation of this was as a precursor to implementing bearer
certificates, which intention somehow got lost.  One reason to have a
server generate unique IDs is to avoid collisions.

> accept components without UIDs, and report back the UIDs they were assigned.

A scenario where you don't know any details at all about the event
you are planning but you know you are having an event would not be too
hard to construct:  for instance, the Downtown Community Center gives
each member organization three events per month and lets them schedule
them on a first-come-first-serve basis.  They do this by having the CS
generate three event-IDs, restrict the event-IDs in an
implementation-dependent
way, generate authorization certificates for each of them, and e-mail the
authorization certificates to the facilitator of the organization for
distribution to the event planners.

Just a for-instance, off the op of my head.

-- 
                                           David Nicol 816.235.1187
"... raised indoors and tested by certified technicians"

---

From: John Stracke <[email-masked]>
Date: Tue, 21 Aug 2001 11:05:02 -0400

David L. Nicol wrote:

>One reason to have a
Yes, but we know how to generate unique IDs on the client side; MUAs 
have been doing it for nearly 20 years.  Involving the server just adds 
an extra round trip.

|eCal Corp.      |Earth: love it or leave it.                  |
[email-masked]|                                             |

---

From: "David L. Nicol" <[email-masked]>
Date: Tue, 21 Aug 2001 19:35:36 -0500

> have been doing it for nearly 20 years.  Involving the server just adds

At the risk of degenerating into name-calling again, if IDs become
authenticaion certificates, you want them being generated by whoever is
going to keep track of them.  Such a GENERATE command would take as
an argument a representation of a access right the current user has, in 
a well defined syntax (the existence of which is implied by the existence
of the VCAR specification) and some other optional arguments such as
expiration time and possibly access list and possibly a limit on the number
of times the certificate can be presented before it burns out, or
other implementation-based accounting or other restrictions; and the
response to the GENERATE command would be an SPKI authentication
certificate.

---

From: "David L. Nicol" <[email-masked]>
Date: Tue, 21 Aug 2001 20:29:00 -0500

Oh, hell.  I meant "become  authorization certificates"

"David L. Nicol" wrote:
> going to keep track of them.

---

From: John Stracke <[email-masked]>
Date: Wed, 22 Aug 2001 10:07:25 -0400

>going to keep track of them.
What you're talking about is not analogous to the problem with 
GENERATEUID.  GENERATEUID just generates the string; your proposal also 
associates it with authorization semantics.  The equivalent in this case 
would be if the client CREATEd an event with no UID, and the server 
assigned a UID and returned it.

|eCal Corp.      |If you're omniscient, how do you know?       |

---

From: George Babics <[email-masked]>
Date: Thu, 23 Aug 2001 11:15:32 -0400

The only thing that searching the archives revealed
was the it was suggested that GENERATEUID be used to
generate unique calids.

  But as you suggested in an other post in this thread,
the create can return the UID for the component it created.
Also, when you create a calendar, the calid can be returned to
the client. This will save calls to the CS.

George

---

From: Alexander Taler <[email-masked]>
Date: Thu, 23 Aug 2001 23:59:17 -0400

GENERATEUID is there for clients who have difficulty generating
properly unique IDs.  iCal recommends that UIDs be based on
hostname or IP address to assure their uniqueness.  This is a
problem in environments where hostnames can be rapidly
reassigned, (dial-up connections or wireless devices) or
environments where hosts do not have properly unique hostnames or
IP addresses (192.168.x.x or 10.x.x.x).

In addition, it may allow applications on small devices to reduce
their memory footprint.

In response to some of John's earlier points:

Using GENERATEUID doeesn't mean an additional round-trip for each
create, a client can request many UIDs at once and store them
locally for that session, or forever.

Sometimes a single event requires multiple VEVENTs to represent
it, in these cases the client needs to add the UID to indicate
the proper linkage between the VEVENTs.

Returning the UID is problematic in the case where multiple
components are created, since the returned UIDs need to be
correlated with the components which were sent.

Alex

>>>>>  "George" == George Babics <[email-masked]> writes:
   George> To: John Stracke <[email-masked]>
   George> Subject: Re: CAP: why do we need GENERATEUID?
   George> Date: Thu, 23 Aug 2001 11:15:32 -0400

   George>   The only thing that searching the archives revealed
   George> was the it was suggested that GENERATEUID be used to generate unique
   George> calids.

   George>   But as you suggested in an other post in this thread,
   George> the create can return the UID for the component it created.  Also,
   George> when you create a calendar, the calid can be returned to the
   George> client. This will save calls to the CS.

   George> George

   George> John Stracke wrote:
   >>
   >> GENERATEUID asks the CS to generate one or more unique UIDs. What is this
   >> for? Why can't the client create its own UIDs, like any other CUA?  Why
   >> should we introduce extra round-trips, and extra work on the CS?
   >>
   >> If there's some strong reason the UID has to be generated by the CS, then
   >> it should still not be done in a separate command; CREATE should accept
   >> components without UIDs, and report back the UIDs they were assigned.
   >>
   >> -- /==============================================================\ |John
   >> Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist
   >> |=============================================| |eCal Corp.  |"Baldric,
   >> how did you manage to find a turnip| [email-masked]
   >> <mailto:[email-masked]>|that cost 400,000 pounds?" "Well, I had to | |
   >> |haggle." --Blackadder III |

--

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: John Stracke <[email-masked]>
Date: Mon, 27 Aug 2001 10:52:22 -0400

>locally for that session, or forever.
Oh, that's a good point.

>correlated with the components which were sent.
True.

OK, so, I withdraw my objections.  I do believe that many CUAs will 
create their own UIDs, though, and we should add explanatory text to 
that effect--otherwise, someone might try to build a CS that requires 
the UIDs in a CREATE to be ones that it generated.

-- 
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |The Net was designed to survive nukes, but not|
[email-masked]|lawsuits. Wait a minute.                      |
\===============================================================/

---

From: Steve Mansour <[email-masked]>
Date: Mon, 27 Aug 2001 08:49:07 -0700

> the UIDs in a CREATE to be ones that it generated.

This is a good point. I will add explanatory text. Basically, if you can
generate GUIDs then you don't need to call GENERATEUID, but if you don't
have guid generation code in your cua, then you can use the server to
generate them for you. 

-Steve

---

From: John Stracke <[email-masked]>
Date: Tue, 28 Aug 2001 09:59:16 -0400

Steve Mansour wrote:

>Basically, if you can
You don't even need guids, really; if you know a reliable hostname for 
your machine, you can use the locallyUnique@hostname approach used for 
Message- Id:.

|eCal Corp.      |Unless. -- The Lorax                         |

---

From: Steve Mansour <[email-masked]>
Date: Tue, 28 Aug 2001 08:40:11 -0700

> your machine, you can use the locallyUnique@hostname approach used for

Remember that people may send this stuff via iMIP to anywhere. So, I
think the only safe thing is to call them GUIDs. You just need to be
sure the UIDs are unique in whatever calstore the component eventually
arrives. So, from the spec point of view, it's best to call them GUIDs.
But as a practical matter, your point is true.

-Steve

---

From: John Stracke <[email-masked]>
Date: Tue, 28 Aug 2001 12:06:08 -0400

Steve Mansour wrote:

>think the only safe thing is to call them GUIDs.
>
Why's that? What's unsafe about @hostname?

> You just need to be
I think that would be an unsafe thing to state in the text; it might 
mislead some implementors into thinking that UIDs have to be GUIDs, and 
reject UIDs that aren't.

Note that RFC-2445 already has examples of the @hostname form.

-- 
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |If God had meant us to be in the Army, we    |
[email-masked]|would've been born with green, baggy skin.   |
\==============================================================/

---

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 28 Aug 2001 11:54:43 -0500

Well a few thoughts come to mind.

Not all reasonable devices on which a CUA might be running have unique
hostnames - PDAs for example, but also corporate desktops that may have only
a DHCP assigned internal IP address - unique within that workgroup - but
likely not within the whole corporation and certainly not within the context
of the Internet (and many times with Windows boxes "hostname" is set to some
default like "hostname" - rather than to something unique)

This could fairly easily result in UIDs being generated, even of a @hostname
form that are not unique - particularly if usage amongst non-unique machines
is similar (everyone checking and making appointments first thing in the
morning - not unlikely that two people would make a calObject at the same
time on identically named/configured devices.) Remember that in many
corporate environments machines are identically configured - relying on DHCP
for networking - but not relying on unique hostnames. Particularly with
laptops even DHCP assigned ip addresses are frequently assigned to multiple
machines at the same time (one to a now disconnect laptop and one to a newly
connected machine for example)

These are not crushing difficulties - however it does point to a place where
the standards document(s) should be careful and should define what is meant
even by such seemingly "obvious" terms as "unique" - and furthermore it
should be clearly spelled out what the standard assumes - and how to handle
some types of common error cases.

For example - one option might be for the server to use its GENERATEUID as a
standard behavior in environments where CUA generated UIDs are unlikely to
also be GUIDs (such as a PDA heavy use case, or a corporate environment in
some cases) - I'm sure however there are all sorts of issues around this
idea that need to be carefully considered and looked at.

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John Stracke
Sent: Tuesday, August 28, 2001 11:06 AM
To: calsch WG
Subject: Re: CAP: why do we need GENERATEUID?

---

From: John Stracke <[email-masked]>
Date: Thu, 30 Aug 2001 10:37:58 -0400

Shannon J. Clark wrote:

>hostnames
[...]

>form that are not unique
This is not news.  This is why Message-ID:s are generated with as much 
randomness as possible, and, ideally, with some other bit of 
probably-unique data in the local-part (e.g., MAC address, if available).

Perhaps what I should have said is, "Why is the @hostname form *less* 
safe than GUIDs?" GUIDs aren't magic, after all; if the system doesn't 
have any unique identifiers around, it won't be able to guarantee 
uniqueness of the GUID.

-- 
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Almost no one has ever wanted a 1/4" drill bit;|
[email-masked]|all they ever wanted was a 1/4" hole.          |
\================================================================/