Subject: RE: [Sip] Max-Forward checking at UAS

From: [email-masked]
Date: Mon, 26 Aug 2002 11:29:13 +0300

> -----Original Message-----
> From: ext Christer Holmberg [mailto:[email-masked]]
> Sent: Saturday, August 24, 2002 11:01 AM
> To: Robert Sparks
> Cc: Adam Roach; Khartabil Hisham (NMP/Helsinki); [email-masked]
> Subject: Re: [Sip] Max-Forward checking at UAS
> 
> 
> 
> Hi,
> 
> I agree with you all that the cookie should not be used to 
> determine if the
> sender does things according to RFC3261 or RFC2543. However, 
> even if you
> say that "z9hG4bK" means that the branch-id is "safe" to use 
> as transaction
> identifier, it indirectly does indicate if the sender does 
> things according
> to RFC3261 or RFC2543, doesn't it? Anyway, there is no idea 
> to argue about
> that :)
> 
> I also agree with Robert that at least a UAS should not care about the
> value of the Max-Forwards header, since the message has reached its
> "destination". I guess another question is what proxies do when they
> receive a message without the header. A few options (all 
> implementation
> specific, I think, so there is no idea to define any specific 
> behaviour in
> the spec):
> 
> 1. The proxy doesn't care, simply forwards the message.
> 2. The proxy doesn't accept the message
> 3. The proxy INSERTS a Max-Forwards header, and forwards the message.
> 
> The first and second options are not so good, since first destroys the
> functionality the header is supposed to provide in the first 
> place, and the
> second destroys the backward compability.

Option 3 is already in RFC3261.

/Hisham

> 
> But, again, I assume it's an implementation issue.... Or?
> 
> A test case for SIPit, Robert?
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> Robert Sparks wrote:
> 
> > I strongly agree with Adam on this point.
> >
> > "z9hG4bK" should only be taken to mean that the remainder
> > is safe to use as a transaction identifier. Basing decisions
> > on processing other parts of a message on its presence or absence
> > is a strong invitation for surprising behavior.
> >
> > Now - to the original point of the thread:
> >
> > The point of Max-Forward is to prevent arbitrary propagation
> > of requests. An endpoint is not going to propagate the request,
> > so having an endpoint reject the request because the header is
> > not present would be pointlessly pedantic. Having it reject
> > the request because it had a value of 0 is a poor choice as well -
> > the request is where it was supposed to be, so go ahead and operate
> > on it.
> >
> > Postel's Maxim alone is enough here - as far as I can tell, there
> > is no value in an endpoint even bothering to _look_ for a 
> Max-Forward
> > header field in a received request, so it should just ignore it,
> > even if it is absent.
> >
> > RjS
> >
> > On Fri, 2002-08-23 at 12:44, Adam Roach wrote:
> > > > -----Original Message-----
> > > > From: Christer Holmberg 
> [mailto:[email-masked]]
> > > >
> > > > The UAS could check the Via branch-id, to see if the
> > > > Max-Forwards header is mandatory for that specific message or
> > > > not. The UAS will have to check the branch-id it anyway, to
> > > > find out if it is able to use it as
> > > > transaction identifier, or if it will have to do it the "old
> > > > way" (ie using CSeq, Call-ID, etc)
> > >
> > > My understanding is that the branch-id magic cookie only defines
> > > that the branch-id itself is sufficient for use as a transaction
> > > ID, and that it doesn't imply anything else about any 
> other handling.
> > >
> > > If we wanted a global token for saying "I do everything according
> > > to RFC3261, and exhibit no RFC2543 behavior," that would be better
> > > acheived by changing the version to SIP/2.1.
> > >
> > > In my opinion, assuming that the presence of the branch parameter
> > > magic cookie has any bearing on anything more than the spec claims
> > > (which is *only* that it can be used for a transaction 
> ID) is begging
> > > for articifical interoperablility limitations.
> > >
> > > /a
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use [email-masked] for questions on current sip
> > > Use [email-masked] for new developments on the 
> application of sip
> 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip