Re: draft-ietf-sip-info-events-00: Legacy usage of INFO

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