Subject: Re: IRIP version 4 (Part 1) - CAPABILITY

From: [email-masked]
Date: Sun, 21 Mar 1999 20:12:01 GMT

Doug replied (in part):
>> Under 3.1.3 CAPABILITY:
>>
>> S: CAPABILITY
>> R: IRIPrev1
>> R: AUTH=KERBEROS_V4
>>
>> The table clearly states the # of times a response may occur.  What
should
>> the sender do if this rule is violated?  For example:
>> S: CAPABILITY
>> R: IRIPrev1
>> R: AUTH=KERBEROS_V4
>> R: IRIPrev1
>>
>> or
>>
>> S: CAPABILITY
>> R: AUTH=KERBEROS_V4
>> R: .
>> R: 2.0
>
>The same thing you would do with any other non-compliant server - you
best.

I know we revised this table and the requirements in Minneapolis but this
thread was before that so...

Having a table that clearly say occurance counts, etc. is insufficient.
There are cases where "your best" is just not going to fly when doing
interop testing.  Other drafts/RFCs that have tables on stuff like this
(ie: HTTP Digest??  I dont have my drafts on my laptop) also clearly spell
out when a failure is fatal and when it is not.  The intent for this was to
avoid some intermediate server (ie: a hostile intermediate server) from
tampering w/the data stream and possibly getting private data, etc.

Just how should my CS proceed when there is no IRIPrev# line??  Assume
IRIPrev1?  Assume something else??  While IRIPrev1 and IRIPrev2 may be
legit in the same response to an iRIP v1 CS, it may be illegal in the real
iRIP v2 draft and the v2 server should be able to detect this and do the
proper thing (instead of punting!)

>> Just what precautions should 'experimental' or non-standard values take
in
>> order to avoid possible name collision w/future "standard" names?
>
>None - standardize or register them!
>
>The fact that there is no way to keep X- names out of the way
>forces them to be registered one way or another.

Ok, then tell vendors exactly how to do this.  You leave the entire concept
up to the imagination..  Are you _assuming_ IANA will just do this
automagically?  Are you assuming some other registration organization??
Dont leave this up to each vendors immagination; it is not a safe choice...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 22 Mar 1999 13:20:12 -0800 (PST)

> From: [email-masked]
> Date: Sun, 21 Mar 1999 20:12:01 GMT
> X-MIMETrack: "Serialize_by_Router_on_Epic/Iris_at_03/21/99_04:43:32_PM" (PVCS 
Build (based on 165) |Mar 17 1999)
> tampering w/the data stream and possibly getting private data, etc.

During inter-op testing, if someone does not send conformatent code -
there is a debate and someone needs to fix their code or they
are not compliant.

If they don't you have two choices. 1) Do not interoperate with
them, 2) alter you code to work with their broken software.

If how it was supposed to be done were not specified, then it
would be a bug in the spec. Is this your point and I missed it?

> Just how should my CS proceed when there is no IRIPrev# line??

Thats an implementation detail. Not a protocol detail. You can
guess, or reject the connection informing the user that other
end is busted. There is NO way to specify each and every action
that a CUA or CSA must assume when talking to a busted implementation.

We need to make sure that the CAP protocol is well written so that
implementors can read and understand the protocol. That's all we can do.

> >> in order to avoid possible name collision w/future "standard" names?
> >

The procedure is specified in RFC 2445. And additions to CAP
should also specify how. Does this meet your requirement?

-Doug