Subject: Re: [sipcore] Mixing old and new H-I

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 1 Aug 2009 23:36:39 +0200

Just to use Hadriels mail to add the comments I was trying to address in the meeting on the same issue.

We were discussing whether the absence of a tag provided information that it was RFC 4244 compliant rather than rfc4244bis. I indicated that understanding compliance with RFC 4244 was irrelevant.

The reason I believe this is that I believe information will be missing no matter what happens for a number of reasons:

i)	If it was RFC 4244 it did not understand the new codings is obviously one of them
ii)	the sender failed to supply the information (I do agree that adding at least one tag should be mandatory in rfc4244bis, but there will always be someone out there who breaks the rules). We also have other parameters applied to entries whose information whose usage is only optional.
iii)	the information got removed along the route, either in the name of privacy or in the name of someones bigger and better SBC thinking it knew best.

So I think it is better to just treat the absence of a tag as "tag unknown" rather than trying to apportion compliance criteria. We then do what we do with what we do with any other unknown information which is try and make the best of the supplied information that we can, same as we already do with RFC 4244 and what we will have to do in the future when someone comes up with a new use case that really required a new tag but previous implementations don't support it.

I think the only reason we would need to worry about RFC 4244 compliance of the sender is if we are trying to return some protocol to the sender in the reverse direction that is based on that compliance. At the moment I have seen no reason for applying that (and even then we should look at option tags rather than the type of protocol used as a means of supporting it).

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: Friday, July 31, 2009 10:16 AM
> To: [email-masked]
> Subject: [sipcore] Mixing old and new H-I
> 
> Howdy,
> Someone got up at the mic during the WG meeting and said 
> "mixing old and new H-I will be really confusing and cause 
> problems".  That person (me) wasn't too smart.  It occurred 
> to me as I sat down that this is really just equivalent to if 
> proxies/middleboxes didn't support 4244 or 4244bis period.  
> 
> In other words, even if we said "start from scratch" and do a 
> new header-name, the fact is that any middlebox not 
> supporting that new header-name would cause the same type of 
> issues as middleboxes supporting legacy 4244 but not 4244bis. 
>  It's unavoidable.
> 
> Mea culpa.
> 
> -hadriel
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>