<relativeCALID> is an identifier that uniquely identifies the calendarWhy? You aren't suggesting a delimiter character are you? That would imply some sort of structure. :-)
on a particular calendar store. There is no implied structure in
a relativeCALID, it is an arbitrary string of characGood choice until that last part. You should preclude some characters like
'/' or <CR>, etc.
The current text reads:
<relativeCALUID> is an identivier that uniquely identifies the calendar on a particular calendar store. There is no implied structure in a relativeCALID, it is an arbitrary string of 7-bit ASCII characters. It may refer to the calendar of a user or of a resource such as a conference room. It MUST be unique within the calendar store. It is recommended that the relativeCALUID be globally unique.
Perhaps you want to tighten this sequence up a bit to beright. In CAP we said they have to be us-ascii characters. iRIP addresses need to be consistent in form with CAP addresses.
only more like the RFC 2038 text that describes HTTP URLs, etc. That way
we wont get raw Kanji, etc that makes parsing nearly impossible.
Under 2.3 Bounded Latency:fixed as we discussed earlier.[IRIP] is designed so that the Sender can either obtain an immediate
response from a request or discover within a known amount of time that
the request cannot be completed...Not quite. "Cannot be" is very different from "has not yet been". Be
careful w/absolutes like that since it may just be a server load issue,
etc.
When the Sender initiates a commandall very good points. Several problems here. First you point out that commands such as RECIPIENT, AUTHENTICATE, or SWITCH do not have the parameter to bound the latency of the reply. Second, the "given amount of time" was poor wording. It should read a "specified amount of time".
that the Receiver cannot complete within a given amount of time, the
Receiver can return an error code to the Sender indicating this
condition.This is only true of the ICALDATA command from what Ive seen. Its not true
from the RECIPIENT, AUTHENTICATE, or SWITCH commands. Also, what is "a
given amount of time"? Are you predetermining the min. response times or
just assuming its "built in."?
the wording was fixed. I'm interested in the opinions of other
as to whether or not we should add the latency parameter to the other commands.
The ABORT command causes the Receiver to discard the currentCurrently it is not specified. Suggestions are welcome.
command and return to the Authenticated state.Pardon me?? Discard what command? Do you mean discard the ICALDATA?? If
so, for all RECIPIENTs or just those not yet completed? Or do you really
mean "abort the current command"? What should be the proper receivers
behaviour on an ABORT for RECIPIENTs that it has already processed?
It is hard to roll-back ITIP messages. In fact, it is impossible. Suppose
I've sent one REQEUST method to a remote site. Suppose it takes a *long*
time. As I'm sending the REQUEST to another site, my latency time runs
out, and the sender tells me to ABORT. What do I do? There is NO
way to undo the REQUEST method already sent to the remote site. There is
no ITIP method that can be used to say "ignore the last thing you got".
begin:vcard n:Mansour;Steve tel;fax:(650) 937-2103 tel;work:(650) 937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0A;Mountain View;CA;94043; x-mozilla-cpt:;-12672 fn:Steve Mansour end:vcard