This behavior should probably be in the document. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Alan DeKok > Sent: Sunday, February 03, 2013 9:02 AM > To: [email protected] > Cc: [email protected] > Subject: Re: [abfab] [radext] New Version Notification for draft-perez- > radext-radius-fragmentation-04.txt > > [email protected] wrote: > > In order to maintain deal with RADIUS clients and servers that do not > > support fragmentation, it would be cleaner to use RADIUS capability > > negotiations (draft-halwasia-radext-capability-negotiation) to > > negotiate use of More-Data-Pending attribute. This would allow all > > RADIUS messages to use More-Data-Pending attribute for fragmentation > > with no exception. > > The existence of a More-Data-Pending in an Access-Request indicates that > the client supports fragmentation. Servers which do not understand that > attribute will return an Access-Accept / Reject instead of an Access- > Challenge. The client will realize that it has not sent all of the data it wants to > send, and will terminate the users session. > > A server supporting fragmentation will start off by sending an Access-Accept > with Service-Type = Additional-Authorization. Clients not supporting > fragmentation will not recognize the Service-Type, and under RFC 2865 > Section 5.6, treat it as Access-Reject. > > There is no need for capability negotiation here. If a client needs to send a > lot of data, it either sends all of the data, or terminates the users session. If a > server needs to send a lot of data, it either sends all of the data, or sends a > Service-Type which causes the client to terminate the users session. > > It would be *nice* to know this prior to terminating the session. > Simply rejecting the user unexpectedly is safe, but unfriendly. > > Any capability negotiation here is a user interface problem. It helps the user > or administrator understand why a session was terminated. It doesn't help > the RADIUS client or server. > > Alan DeKok. > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
