Re: IRIP version 4 (Part 1) - CAPABILITY

[Doug Royer <Doug.Royer@xxxxxxx>]

> From: Bruce_Kahn@iris.com
> 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)
> 
> 
> Doug replied (in part):
> >
> >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.

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.

> >> 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...

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

-Doug