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

From: Adam Roach <[email-masked]>
Date: Fri, 23 Aug 2002 12:44:14 -0500

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

---

From: Robert Sparks <[email-masked]>
Date: 23 Aug 2002 13:05:52 -0500

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

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Aug 2002 11:00:39 +0300

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.

But, again, I assume it's an implementation issue.... Or?

A test case for SIPit, Robert?

Regards,

Christer Holmberg
Ericsson Finland