General comments:
* I really dislike how the meaning of UAC/UAS has been changed from
RFC3261. This is really confusing and I think complicates presentation
of the material
* I think the negotiation of supported types is not sufficiently well
defined. We're going to run into many of the hard cases we ran into for
offer/answer - so lets address them now. What happens if, in an early
dialog, there is a reverse UPDATE that changes the send/recv packages,
and then a 2xx to the INVITE arrives with a different set? Which takes
priority? What about mid-dialog exchanges that are rejected, do we
revert back to the previous set? Indeed I don't think we should model
this on O/A at all.
* The draft allows for multiple packages to be in a single INFO. Egads,
that just complicates life. Multipart support is already a mess in SIP.
Do we REALLY need this? Cant you just send two INFO requests? If a
single INFO has a single package, we also don't need the cid mechanism.
Less is more (I know this had some discussion already on the list...)
* I don't like the behavior whereby, if a UA receives an INFO with an
unknownn package, we terminate the dialog. Why so extreme?
* I know we've discussed this one, but I disagree that the event
packages HAVE to be specification required. I think we should allow for
vendor prorpietary usage. My suggestion is to define a vendor tree for
info event packages.
* Section 7.1 includes some of the considerations in the info-litmus
draft, but only some. We should either fold it all in or else split it
all out. In either way, its really important to separately consider the
question on whether the exchange should take place in the signaling vs.
media path, and then if signaling, whether to use INFO, event pakcage,
or new method, etc.
Specific comments:
The purpose of
the INFO message [RFC2976], on the other hand, is to carry
application level information along the SIP signaling path.
There is no clear definition here of 'application'. I think that merits
some discussion.
Info Package negotiation is an offer/offer mechanism. The UAC may
offer a set of Send-Info and Recv-Info packages in the initial
INVITE, the UAS offers its set of Send-Info and Recv-Info pacakges in
I think its a bad idea to use the term 'offer/offer' since it sounds
like this is related to the SDP offer/answer mechanism. Suggest the word
'propose' instead of offer.
In this section, "UAC" is the User Agent Client from the perspective
of the INVITE method. That is, it is the User Agent (UA) that sends
the initial INVITE method request. This may be somewhat confusing if
the User Agent Server (UAS) from the perspective of the INVITE method
sends an INFO method request.
This contradicts the definition in rfc3261; the role of UAC and UAS are
on a per-transaction basis, not fixed for the duration of the call based
on the initiate INVITE that established the session!
The
general rule is before a UA may begin sending INFO methods with a
given Info Package, the sending UA must first indicate it wants to
send the Info Package by listing it in a Send-Info header in the most
recent dialog negotiation and the receiving UAS must positively
indicate it is willing to receive the Info Package by listing it in a
Recv-Info header in the most recent dialog negotiation.
what if the previous exchange omitted Send-Info or Recv-Info, but an
exchange prior had contained it?
A UA MAY list multiple packages by enumerating the package name(s),
separated by commas, as values for the Send-Info and Recv-Info
headers in the session establishment.
not just at establishment, but at any time.
Such Info Package capability negotiation MUST occur within the
context of a single session negotiation exchange.
this is very vague in terms of what it means.
Similar rules apply for late Send-Info / Recv-Info negotiation, such
as an empty INVITE, followed by an offer in the 200 OK and the
response in the ACK.
In which case, this should be defined more generically rather than
writing it in terms of INVITE and just say, 'oh, it works in other use
cases too'
The INFO message MUST NOT change the state of the SIP dialog. The
only exception to this rule is for specific failure responses as
documented in RFC 5057 [RFC5057], which may cause the INVITE dialog
to terminate.
We should clearly enumerate what this is. Can we update Contacts? Is
INFO a target refresh request? What about P-A-ID? Or From/To URI?
OPTIONS Processing
A UAC, the sender of the OPTIONS request, MAY include Send-Info and
Recv-Info headers, populated appropriately for the packages the UAC
Burger, et al. Expires May 7, 2009 [Page 14]
Internet-Draft INFO Framework November 2008
supports. The UAS MAY include its set of Send-Info and Recv-Info
packages.
I think you should make this a SHOULD (inclusion of Send/Recv Info).
Because there are numerous situations where a SIP method request can
carry a payload, any INFO method may contain body parts in addition
to the payload associated with the Info Package.
hmm, why? This complicates things. KISS.
9.5. Creation of the Info Packages Registry
You should show an example of what the actual table in the IANA registry
looks like and include the 'nil' there.
There are no specific security issues for this mechanism, beyond
those already applicable to SIP-based session signaling. In
particular, if one does not protect the SIP signaling from
eavesdropping or authentication and repudiation attacks, for example
by using TLS transport,
I disagree with this statement. There are new considerations here -
we're now exchanging APPLICATION data in SIP, and this increases
sensitivity of the data depending on the application. For example
considering using INFO to send typical form-data, like a credit card
number....
Minor:
[RFC2976] to include explicit negotiation of supported Info Packages
in the INVITE transaction and indication of the Info Package to use
by using a new header field in the INFO request.
[RFC EDITOR NOTE: Please replace "This draft proposes replacing"
with "This draft replaces" in the final edition.]
there is no need to make rfc-ed do this work. Write the document to
reflect what it is meant to look like as an RFC.
The signaling path for the INFO method is the signaling path
established as a result of the call setup.
dialog setup
a signaling
path involving SIP proxy servers that were involved in the call setup
and added themselves to the Record-Route header on the initial INVITE
message.
or b2bua's.
The UAS MUST send a 481 Call Leg/Transaction Does Not Exist message
if the INFO request does not match any existing dialog.
this repeats already-defined behavior in rfc3261. Remove.
By definition, such uses
have relied on either static local configuration or implicit context
determination based on the body Content-Type or Content-Disposition
value, or some proprietary mechanism.
'have relied on..." you don't say what they've relied on these FOR.
7.2.7. Rate of notifications
I think this should be rate of INFOs
--
Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South
Cisco Fellow Iselin, NJ 08830
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
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
