reported by Vijay Gurbani
54 IETF SIP WG meeting
REFER goes to IETF last fall after IETF LC, but did not have agreement on a critical piece. Will discuss today.
Robert Sparks, REFER Open issues Last discussion demonstrated confusion about the use of sip-events. refer-3265disc.txt adds clarifying discussions. But, no implementation of optional subscripons, so mechanism is not needed. Implicit subscription is mandatory. Will submit refer-06 this week reflecting: 3265disc without the Require/ Supported mechanism; mandatory subsl lightweight way of terminating subs.
Brian Rosen asked if anyone wanted to run LC again; no one objected to this. So, it is back in the IESG queue without a LC.
Referred-By, draft-ietf-sip-referredby-00.txt I-D submitted after interim meeting; uses S/MIME mechanism described in -sip-identity-00 to address security issues. Very little discussion on list. I-D is sitting there, if anyone wants to comment, do so. Brian: will schedule LC soon; so get comments in ASAP.
MESSAGE Open Issues, Ben Campbell Now on -05; been in IETF LC since Las Vegas interim meeting. Some changes based on LC feedback Big issue: congestion control; 05 adds wording that says that if the UAC knows that MESSAGE will not cross a non-congestion-safe length, it can exceed this limit. Added clarification language to the Expires header, which says that a 0 value implies immediate delivery. Added clarifying language. Suggestion to state that a client MUST register with 'methods=MESSAGE'; currently a SHOULD. Current plan is to leave it as a SHOULD.
SIP WG Stuff, Jonathan Rosenberg Caller pref. changes: rewrite for dependence on rfc2533 (a syntax for media feature sets). I-D is completely rewritten. This is about matching what the callee desires with what the caller can do. The original I-D did 'know' about rfc2533, but discarded it as too complicated. In hind sight, probably not a good idea; want to use the work in rfc2533. We have simplified the algorithm in caller prefs to make it simpler than rfc2533. Syntax of caller pref is more or less unchanged; internal semantics are. Some semantic changes: 'type' feature tag now only for complete types; added a 'media' tag for top level types -- audio, video, message (2 tags now, 'media' and 'type'; will break backward compat.) Added new automata tag, boolean, for robots, VM servers. Added events tag for SUBS/NOT. New: explicit preferences. All previous implicit computations (like an incoming INVITE was sent out to a UA whichJDR was implicitly supposed to support an INVITE) are now explicit. More changes: URI matching is allowed, but restricted -- all URI params ignored. Eliminate the '&' construct.
Dave Oran: What is the semantic of & conjunction -- example: why does media=audio&video does not make sense. JDR: Consider a n-axes, where a point in this n-dimension has exactly n discrete co-ordinates; each co-ordinate has a value (example: in a 2-dimension space, x and y co-ordinate have 1 and only 1 value). For the co-ordinate 'media', it is not possible to have 2 values, 'audio' and 'video'
Adam: But we can do video=yes and audio=yes, 2 boolean values.
JDR: If people agree on this, we can work it in.
???: What happens when 'touch' and 'smell' are made new MIME types? Every IANA registered media types become a preference?
JDR: Will put some wordings in the draft to handle new top level MIME types.
Open issues: 1 - Overlap. 2 ways to do one things -- Methods and Allow ostensibly do the same thing. Events and Allow-Events, ... Solution: Allow both, with headers taking priority.
Patrick Falstrom: People should read RFC 2703 to make more sense about content negotiation. That may solve many misconceptions or generate new ideas regarding caller prefs.
Open issue 2: other extensions - caller prefs has no way to indicate which Contact params are 'it's' as opposed to other extensions. It may not matter. We should state it as a issue, though.
Need at least one more rev based on WG meetings and other talks.
SIP-NAT, Jonathan Rosenberg. Total rewrite; turning it more into making sure SIP can work with STUN, SPAN, TURN, ... Ultimately, TCP is the answer. Should we turn this I-D in for last call? [No one disagreed.]
Brian Rosen: Anyone believes open issues in session timer? [No one spoke up]
Digest based authentication, James Undery, Sanjoy Sen, Vesa Torvinen draft-undery-sip-auth-01: list dialog indicated that the old I-D was too comples; current one is less complex than previous drafts; fixes Authentication-Info, bid-down protection and header integrity protection. Integrity protection is now done by including "message/sipfrag" in the body. Is it still too much? Do people still want it? Henning: This is overdue; we should do it. Are there any parts that are controversial? We should not let it hang around; if it is not acceptable, then people should look at other solutions. ???: I agree with this; we need some method to protect headers. I am not 100% convinced that this is the best way to go, but something along this line is sorely needed. James: S/MIME is another way. Henning: I am not holding my breadth that every IP device will implement S/MIME for registration; this seems to be a better option. Jon: 2 choices: extend digest or shrink S/MIME. Maybe this is the right way. Brian Rosen: People have to look at this and prioritize it for LC. We will have a discussion on this with our security advisors.
SIP Congestion Safety, Dean Willis Open Issues: In UDP, no way to aggregate UDP transmission timers across multiple transactions. Each UDP transaction will have its own individual transaction timers. [Long discussion ensued regarding the advantages/disadvantages of UDP, lack of security in UDP, why UDP should be deprecated, the lack of scalability of TCP.] JDR: What is the consensus? Do we agree to this I-D as an enhancement to SIP for congestion control? [Dean took a hum: Is congestion management something we should deal with? Hum indicated that yes, it is.]
10 minutes left on agenda -- mike opened for other topics.
15 Jul 2002 06:05 -0500