Re: KINK issue list rev.2

> On Wed, 2005-02-02 at 12:32, Sam Hartman wrote:
> > >>>>> "Michael" == Michael Thomas <[email protected]> writes:
> > 
> >     Michael> So I'm rather ambivalent. The current phrasing will
> >     Michael> certainly do it's main job: stopping a receiver from
> >     Michael> incorrectly parsing future versions and the potential
> >     Michael> exploits that could result.  Maybe we really should leave
> >     Michael> it at that if for no other reason from a security/system
> >     Michael> analysis standpoint.
> > 
> > If you want to leave it please at least say that the receiver must
> > send back the appropriate bad version error.
> 
> Well, I'm actually asking what others want here. I sort
> of tend toward this, but it's not just my call here...

I don't think KINK will have minor change often, and I don't think the
minor version will bring worth things to KINK.  so I feel that I want
to remove the minor version from KINK specification.

However, if we will leave it, it is policy matter to process a message
with a higher minor version.  so we have to describe like below:
	if a endpoint receives a message with a higher major version
	number, it MUST drop the message and SHOULD send a KINK_ERROR
	with KINK_INVMIN.