Re: IRIP version 4 (Part 1) d

[sman@xxxxxxxxxxxx (Steve Mansour)]

Bruce_Kahn@iris.com wrote:

>    Under 3.1 Commands:

>   What good is the CAPABILITY command in the Send state?  This should
> be
> restricted to the Connected and Authenticated states (since it could
> vary
> based on if the user is authenticated or not).

We'll hash this one out in our CAP discussions. IRIP will be consistent
with CAP.

>   What about some command  to enable TLS encryption or authentication
> of
> data ala StartTLS of LDAP & IMAP (or STLS for POP3)??!  This would be
> good
> so we could avoid having irip: and irips: and taking up 2 TCP/IP
> ports.  Be
> sure to add the CAPABILITY command to the new modes for this case or
> better
> clarify that the results for a given mode (ie: Connected mode but w/
> or w/o
> TLS could yield different values! See LDAP RFC for examples using
> SASL).

We'll hash this one out in our CAP discussions. IRIP will be consistent
with CAP.

>   Your state diagram at top has SWITCH valid in the Connected state
> but
> your command table does not.  Pick one.

fixed.

> A response MAY include an [ICAL] object.  This is followed by a
> <CRLF>.<CRLF> and a reply code.
>
> If there is no iCal object then MAY or MUST there be a <CRLF>.<CRLF>
> before
> the reply code?  Clearly state when that sequence will or will not be
> there.

fixed.

> Under 3.1.1 ABORT
>
> The ABORT command is issued by the sender to stop an ICALDATA request
> from being processed further.
>
> Not 100% accurate.  ABORT can be used in the Send mode to abort the
> process
> moving into the Receive mode via the ICALDATA.  It can also be issued
> in an
> attempt to end a DEQUEUE command (w/o being in the Idle mode).

how about: The ABORT command is issued by the sender to terminate a
command whose latency time has been exceeded.

> According to the text the general format of commands and arguments is:
>
> <command> [arguments...]
>
> Howeve the example under 3.1.1 has:
>
> S: ICALDATA:10
>
> Note that there is a ':' instead of a LWSP as semi-expected.  I didnt
> check
> the BNF later in the draft yet so this may be legit although Id
> recommend
> LWSP be used as the delimiter for commands so parsing out a command is
> as
> simple as looking for the 1st LWSP or the terminating <CRLF>

yep, it has been change to LWSP

> In that same example is the line:
> <10 seconds elapse...>
> R: .
>
> This gets back to is <CRLF>.<CRLF> always there before a reply code or
> not.
> Not clear if this is on purpose or residual so Im flagging it.
>
> In the example you see:
> >R: 2.0.2 irip://cal.example.com/abc
> >R: 2.0.2 irip://cal.example.com/def
> but later in 3.1.4 you see a different argument to the reply code of
> 2.0.2:
> >R: 2.0.2  Reply Pending

this was a mistake. currently there is no text after a reply code

> so Im curious which should be used and if they follow the iCal/iTIP
> format
> for reply codes.  (Need that online draft handy!)

fixed.

> The Receiver will issue the 8.2 reply code if it receives an ABORT
> when
> the ICALDATA command is not in progress.
>
>   Make that ICALDATA or DEQUEUE commands.  The text talks about
> returning a
> reply code of 8.2 when there is no ICALDATA (or presumably DEQUEUE!)
> command in progress.  I infer from this that 8.2 is "Inappropriate
> command"
> or something like that.  However when I look it up below it is defined
> as "
> ICAL OBJECT TOO BIG".  Seems to me that this description is wrong or,
> more
> likely, there is just a need for a new reply code meaning
> "Inappropriate
> command".  This reply code could also be used for DISCONNECT in the
> Send/Recieve modes, etc.

Yea. 8.2 was wrong. It should have been 2.2 (An ABORT or CONTINUE was
received when no command was in progress). The error table in the IRIP
text we sent out was just wrong. 2.2 was not even listed.

it's fixed.

> Under 3.1.2 AUTHENTICATE:
>   If we add some form of "StartTLS" command then dont forget to update
> the
> text here to allow for it before or after authentication takes place.
>
>   The text indicates that the reply code of 6.1 is to be used for
> mechanisms that are not supported.  However I dont see this listed in
> the
> table of reply codes later on.  If this is not in iCal then dont
> forget to
> add it here.  Othewise, never mind.  (The same applies to the other
> reply
> codes expliclty listed in this block of text; 6.x family)

as mentioned, the error table was horked.

>   As before, explicitly declare what the behaviour is to be when
> reauthentication fails (ala LDAPs RFC or was that LDAP w/SASL?)
>
> Under 3.1.2.1 Authentication with Proxy Access
>   You use the term "caladdress URL" or "caladdress" but elsewhere you
> refer
> to CALID.  Stick to one format.

fixed

> Also, are the allowed values
> relativeCALIDs or Qualified CALIDs?

both. same rules as cap. if they are relative, the scheme defaults to
"irip" and the CSID defaults to the host name for the IRIP server.
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