On 9/30/16 3:52 PM, Roman Shpount wrote:
Well, I agree with you in theory, but this is one of those horses which
has been out of the barn for a long time. No amount of standards
clarifications will resolve this now due to how common it is to add
customer parameters to SIP headers and how many of those parameters are
now used in legacy applications. It might be a good idea to test and
warn of such custom header use during SipIt events to avoid them in the
future.
Note that I didn't say that receivers should stop ignoring and
forwarding these values.
The existing implementations can keep doing what they're doing. Its just
that anybody that wants to can call them out as violating the specs, and
be justified in doing so.
But we could define a compliant way to do this and then start
encouraging implementations to do that instead.
The only actual danger in what is going on now is that there is no
policing for uniqueness of the parameter names. That *could* cause a
problem someday, though the odds of that probably aren't very high.
Thanks,
Paul
As far as Via is concerned, the better and standard compliant practice
is to encode any application specific data in VIA tag parameter using
some sort of proprietary encryption scheme. It is guaranteed that Via
tag will be returned to the proxy unmodified.
Regards,
_____________
Roman Shpount
On Fri, Sep 30, 2016 at 3:16 PM, Paul Kyzivat <pkyzi...@alum.mit.edu
<mailto:pkyzi...@alum.mit.edu>> wrote:
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>
<mailto: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
