[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ICAP:string literal



Kiran,

The CalSch working group is currently gathering requirements for the
Calendar Access Protocol.  After this work has been completed, participants
of the CalSch working group will author a calendar access protocol internet
draft.  After much feedback and many iterations of that draft, it will
eventually become a proposed standard that will allow interoperability
between all calendaring products.

Today, there are two calendar access protocol individual submissions.  ICAP
(which you are asking quesitons about in your mail) is one of these
individual submissions.  Although the eventual proposed standard will no
doubt leverage good ideas from all the current submissions, there is no
guarantee that the eventual standard will be compatible with any of the
current individual submissions.

If you are building calendaring products, and this standard is important to
you, you should read over the current requirements document and send the
group feedback on it.  Now is the time.

Thanks,
Alec Dun
Microsoft.

-----Original Message-----
From: Kiran Josyula [mailto:kiran.josyula@cyberquestsys.com]
Sent: Thursday, June 18, 1998 4:03 AM
To: IETF-calendar@imc.org
Subject: ICAP:string literal



Hi,
We are developing a Calendaring application using ICAP.
What I understand by the String literal specified in the ieft-draft
is that it should carry the octect count enclosed in {} before actually
sending the octect data.
I noticed that in none of the examples given in the draft the octect count
is the actual count of the characters sent after it.

Secondly the definition also says that the client must wait to receive
command
continuation request after sending the octect count before sending the
octect data.
The example shown in the case of APPEND command fails to comply with this
rule.

Help will be highly appreciated.
TIA
kiran