the following paragraph of Section 5.2 puzzles me:
If a server receives an INFO request with a body it understands, but
it has no Info-Package header, the UAS MAY render the body. Note the
semantics of "rendering" is up to the Info Package definition. The
UAS MUST respond to the INFO request with a 200 OK. This enables
legacy use of INFO.
Now it states that is to enable legacy use of INFO, but at same time
refer to the Info Package definition
that is something only for the new usage.
IMO with this text it would be possible send also an INFO request the
other end is not willing to receive,
it is enough not include the Info-Package header. Is this can be seen as
a possible security problem?
Thanks
Sal
Paul Kyzivat wrote:
While I see rules in 5.1 and 6 that permit use of legacy packages at
the INFO UAS, I find no rules that permit sending a legacy INFO. I
guess it must be possible to use legacy INFO even when both sides
support this new info package mechanism. And I guess the evidence that
a UA *doesn't* support this new mechanism (by the absence of the
headers in request/response) is just equivalent to one that explicitly
negotiates support of no packages.
Regarding registration if INFO packages - I thought we also wanted to
introduce a registry for legacy usages of INFO, to encourage them to
come out into the daylight. I guess maybe that would be a separate
registry, since the key for it will have to be Content-Type. So it
*could* be established from a different document. But I think this is
the likely place to do it, since its the place where all the eyeballs
will be. I think the rule for registering those needs to be that one
can only be registered if the Content-Type has not already been
registered, and it was in *use* with INFO prior to this document
becoming an RFC. (The registration itself could be done later. I guess
it would be the honor system.) Any usages being deployed after this
becomes an RFC would be required to use the new mechanism.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
