Roman,
On 9/30/16 2:27 PM, Roman Shpount wrote:
On Fri, Sep 30, 2016 at 2:03 PM, Paul Kyzivat <pkyzi...@alum.mit.edu
<mailto:pkyzi...@alum.mit.edu>> wrote:
The inclusion of generic-param is a provision for future extensions
with backward compatibility. It doesn't mean that anybody is
*permitted* to add whatever they want. (It takes a published RFC to
validly define a new header field parameter.) So if you *insert*
values that haven't been properly defined and registered then you
are violating the specs.
This interpretation would break a lot of SIP implementations. The reason
for this is that Via and Route generic parameters are used by stateless
proxies to store application specific state. There is no other place to
put it. Skype for business was one example. I can probably find another
10-15 examples similar to that from other products.
Maybe it would. But I think it is more than simply *my* interpretation.
RFC3427 says:
Anyone who thinks that the existing SIP protocol is applicable to
their application, yet not sufficient for their task must write an
individual Internet-Draft explaining the problem they are trying to
solve, why SIP is the applicable protocol, and why the existing SIP
protocol will not work.
And RFC3968 says:
SIP header field parameters and parameter values MUST be documented
in an RFC in order to be registered by IANA. This documentation MUST
fully explain the syntax, intended usage, and semantics of the
parameter or parameter value. The intent of this requirement is to
assure interoperability between independent implementations, and to
prevent accidental namespace collisions between implementations of
dissimilar features.
How can you read those to allow use of unregistered values?
If there is need for this, then there ought to be a revision to carve
out a namespace for proprietary header field parameters, in general, or
perhaps only for Via.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
