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

Re: IRIP version 4 (Part 1) f

Under 3.1.4 CONTINUE:

  Why not use a LWSP as the delimit rather than the ':'.  (Same discussion
as for use w/ICALDATA above.)

already fixed :)
  The example does not jive w/the discussion of ICALDATA that follows.
According to ICALDATA, the response should be MIME encapsulated iTIP
message but the example just has:
S: CONTINUE:10
R: BEGIN:VCALENDAR
...
(no MIME encapsulate, just raw iCalendar/iTIP)
good catch.
fixed.
Under 3.1.5 DEQUEUE:

  I just realized that there is no latency option for this command hence
the state diagram is a bit misleading for this command as the sender would
never be in the Idle state for this command, they are always in the Receive
mode until it completes.  I appreciate the KISS on the state diagram but
its not totally accurate (</nitpicking>)

I see what you mean.

Any suggestions on the state diagram?

Under 3.1.6 DISCONNECT:
>It can be sent from any state.

Not true.  The state diagram has it only valid in Connected and
Authenticated.  If in the Send, Receive, or Idle states the sender must
ABORT first and then DISCONNECT.  Pick one be consistant.

Right. People were loud and clear about the one to pick: DISCONNECT can happen anywhere. The problem was simply that the character drawing of the state diagram gets too ugly. It seems to me we have the following choices: Currently I've added the note to the text.
Under 3.1.7 ICALDATA:

The line:
R: <MIME encapsulated ITIP Message>
is misleading since prior (and later) examples show just "R: ." and "R:
2....." lines w/NO returned MIME encapsulated iTIP message.  Which do you
intend; mandatory iTIP message as a reply or optional?  Later text implies
its optional but is phrased such that the entire reply (iTIP message, CRLF
. CRLF and reply code) is optional:
>The receiver
>reply may optionally contain an ITIP message followed by the special
>sequence <CRLF>.<CRLF> followed by a reply code for each of the
>recipients.
(Rephrase so its clear that just the iTIP message is optional please)

It now reads:
The receiver reply MAY contain an [ITIP] message. The reply MUST contain the special sequence <CRLF>.<CRLF> followed by a reply code for each RECIPIENT.
Also, the example format shows:
R: .
R: <reply code>
but MANY of the examples in the draft return several reply codes.  Just
what is the proper behaviour: 1 reply code total or 1 reply code per
ATTENDEE/CALID??  The last text of the 3.1.8 section covers this but it
should be in this section too or in place of in 3.1.8.
I'm hoping the phrase above covers this for you. In particular "... followed by a reply code for each RECIPIENT.  The RECIPIENTS may be different from the ATTENDEEs in the ICAL body. In fact, in the case of a PUBLISH, there are no ATTENDEEs.
There is no new reply code for "Unable to process" or "Unable to accept or
queue" for a particular CALID.  An example would be an employee whose left
the company but they do not have a forwarding address and wont want to
queue it up for no reason (or just a bogus CALID that has a typo, etc).
Actually I see later this is described as 5.3 (under 3.1.8) but its not
defined anywhere in the draft.  However this code is for the RECIPIENT
command and does not really cover the "Unable to accept or queue" for some
CALID that it thought it could queue for.
This has been a constant area of confusion. There are reply codes defined in iTIP.  This draft was intended to list those reply codes needed that were not specified in iTIP. Even though we were pushed that direction in the beginning, it's probably a bad idea. We should probably just repeat the iTIP error codes in this draft and add the ones we need so that implementers can refer to one table of reply codes.

What do you think?

Under 3.1.8 RECIPIENT:

  There is mention of a reply code 5.3 for "unknown" CALIDs but its not in
any table in the draft.

it's in ITIP
Under 3.1.9 SWITCH:
>After a switch command is executed and the
>new Sender authenticates, all queued commands that the new Sender has
>queued for the new Receiver will be delivered.

Whoa folks! This is at odds w/the state diagram and all prior text.  There
has been no mention of automagically processing queued "commands" (I assume
these to be iTIP messages really as opposed to iRIP commands).  Where did
this concept magically spring from??

hmm... That was the sole purpose for the SWITCH command. It's mission is this:

Company A's irip server can connect to Company B's irip server. But, due to firewall issues B cannot connect to A. So, the two companies establish a trust relationship between each other. Irip messages sent from B to A are queued on B.   A periodically polls B to collect queued messages. After A connects to B, A issues the SWITCH command.  Anything queued is then transferred from B to A.

Do you see another use for the SWITCH command. Could you give me an example?

>The Sender must be in the
>authenticated state before the SWITCH command can be used.
This does not jive w/the state diagram or prior text that claim SWITCH can
be done in either the Connected OR Authentiated states.
That's not the way I read the state diagram. I read it SWITCH can be executed from either the Authenticated or Connected states. But in either case, after SWITCH is executed, the connection state goes to Connected.

What is confusing you here?  I'll try to clear it up, but I don't see the problem.

-Steve
  

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