Subject: Comments on Guide to Implementors

From: [email-masked]
Date: Fri, 06 Aug 1999 20:09:47 GMT

I've put below a "snip" from a note I received from Eric Busboom of 
Qualcomm regarding our Guide to Implementors RFC.  I wanted to make sure 
it made it to the list.

- - - - - -

At 07:46 AM 7/29/99 , you wrote: 

The first draft of the outline for topics to be covered in the Implementor 
Draft is done.  Please go to the URL included in the note and provide 
feedback on what you see, what's missing, etc.  thanks. 

My development team and I could really use something like this -- great 
idea. I would be happy to help with this document, either editing, 
reviewing, or writing, since I suspect that it will be just as valuable to 
someone else as it would have been to me. 

Below is a few of the confusing issues that I and my team have confronted 
while developing both a server and a CUA. 

-- Choosing a transport method: How to decide wether to book a component, 
such as a meeting request, directly onto a calendar via CAP or send it via 
iRI, assuming that you have both options. Where should iMIP messages go? 
To the server, or to the CUA?

-- Publishing calendar addresses. Is it necessary for a user to publish an 
iRIP, CAP and iMIP address? What kinds of addresses should be published, 
and to whom?

-- Translating values of components: If my server reads in a DATE-TIME in 
the local timezone, is it OK to translate it to GMT? If it gets a DURATION 
of "14 days", is it OK to translate it to "2 weeks"? If I get a CATEGORIES 
property with multiple values, can I translate it into multiple CATAGORIES 
properties, each with one value?

-- Hard limits: How do I handle the case where a CUA sends an attachment 
that is too large for the server to handle? Or, a description string that 
is too long?

I am sure I will think of more as development continues. 

eric.

---

From: [email-masked]
Date: Sat, 07 Aug 1999 02:08:46 GMT

<fd>This depends entirely on what access rights the originator anticipates 
that it has in the recipients system. When sending an invitation to a 
foreign system, I would expect that I would use an iMIP to assure the 
greatest possibility that the invitation would be accepted. In addition, 
it greatly depends on what calendar address I have for the recipient. My 
contacts section only has a single entry for the calendar address.</fd>

-- Publishing calendar addresses. Is it necessary for a user to publish an 
iRIP, CAP and iMIP address? What kinds of addresses should be published, 
and to whom?
<fd>No. You would include in your vCard the address that you think is 
_most_ appropriate for MOST of the potential recipients. As for which 
addresses that I think we should publish, I believe that the LOCATING 
document is the proper focus for conveying "what kinds of addresses" one 
is supposed to use.</fd>

-- Translating values of components: If my server reads in a DATE-TIME in 
the local timezone, is it OK to translate it to GMT? If it gets a DURATION 
of "14 days", is it OK to translate it to "2 weeks"? If I get a CATEGORIES 
property with multiple values, can I translate it into multiple CATAGORIES 
properties, each with one value?
<fd>Egads, GMT? Let's get PC here. It's UTC, man! No, it is not conformant 
to change the "Local" date/time value to "UTC". The "Local" time format 
has precise semantics that is entirely different than the UTC format. The 
"Local" time is only supposed to be used when you want to specify a 
"floating" time. Where is DURATION being used? This is important to 
determine if it is appropriate to substitute 14 days. Yes, you can 
substitute multiple categories with a single text value per property for a 
single CATEGORIES with a list of text values.</fd>

<You send back an error.</fd.