Reported by Vijay Gurbani, vkg@{lucent.com,research.bell-labs.com,acm.org}, edited slighty by Dean Willis
19:30 CST meeting started 19:33 Agenda accepted
Work Plan update:
SIP Change process, Allison Mankin:
This is not a SIP draft; it is an individual transport area draft. People have said that there is no need to control SIP information. The Replaces header was done in a freeform manner -- this is not good. WG discipline needed over extensions of SIP. RFC 3261 (new bis) has an IANA consideration which is very different then what you have seen before. You need a standards track RFC for headers, method, response codes, warning codes. One place you do not need to do this is for the Events RFC -- just need WG yes for these. serverfeatures did not go too far with IESG since it offered unbridled extensions. We now have P-header (not X-header, more constrained). Still need a RFC, but you do not have to have the buy in of SIPPING or SIP. The string with P- is reserved if they are to have a future life. Henning: while I agree with the notion, the naming has the same problems that X headers had. Attaching a meaning to "P-" is not good. Allison: They do not have option tags and have to have applicability statements. Henning: There are 2 issues: naming and process/applicability. If we have a header name which was registered (say, foo); that header has the property that as long as it is in the non-RFC track, it looks like a normal header. If it reaches standards track, it retains its name. Lets say P-bar header becomes popular and widely implemented. Now, if P-bar header goes to standards track, they will have to rename this header. Allison: can you make a P-header a standards track header -- add an option tag. Dean: The P- name will still be registered and be useful. Now you will basically have to track P- and non-P extension headers -- makes the symbol table little large -- that's okay. Dave Oran: feel uncomfortable in mixing naming conventions and algorithimic behavior. I do not like the idea of having to parse inside header string. Jonathan Rosenberg: The name of the option tag is unrelated to the name of the header. Henning: HTTP extension model is different then SIP extension model. There is no correlation in header names and option tags. Allison: If the I-D has any implications of this sort, we can fix it. Gonzalo: We have option tags that have no headers associated with them. Keith Drage: We need to make sure that this I-D does not contain any requirements on SIP implementation -- a SIP implementor must not have to read this I-D.
The UPDATE method - Jonathan Rosenberg :
Open issues 1) Glare with PRACK - UPDATE only specifies glare resolution with itself. You can have glare with PRACK. Rejecting PRACK is bad. Solution: can't send UPDATE if you have sent an answer in 18x for which you have not gotten a PRACK. Will put some words with general caveats. 2) Repairable response codes -- automata can fix these without human intervention. What about 493 Undecipherable? May require user intervention to fix it. Proposal: include it, add text saying it retries if it would otherwise retry with that response. [No one objected]. 3) Generate 155 instead of 4xx MAY or SHOULD -- for backward compatibility. SHOULD is better if the UAS supports this capability, the proxy may not. This makes it work at proxies transparently. Comment: This text is screaming for a reason header, otherwise the UAC will have to infer what the problem is. JDR: I did not talk about reason header for a reason -- it is on a slower track. For the basic cases we are worried about immiedately, the UAC can infer from the headers. Going forward, the reason header is the way to go. Gonzalo: The last review of the reason header already has this, so we can use it. Jonathan: Does the group agree that the message sip (or sip frag) is the appropriate approach? Or wait for the reason header (which is on a slower track). Rohan: Can we pull out 155 out of this, then? [No consensus on this]
Manyfolks open issues (Gonzalo Camarillo) draft-ietf-sip-manyfolks...-05.txt
We are now defining a framework for preconditions of different types. We define the current status of the precond vs. desired status. We always know if current status is better or worse then desired status. Two status types: e2e -- always present in manyfolks (-04). Segmented status type introduced in -04.
Open issues: Meaning of Require: precondition -- 2 appraoches: I refuse everything I don't understand. Or be liberal and accept the offer if the preconditions can be met without your intervention? Which is better? 1 or 2? Comment: you can have a thing called "criticality" which gives a hint on what to do. Gonzalo: I will decide after speaking to Mark.
Reason code, Gonzalo Camarillo.:
Requirements: same functionality needed in several WG items -- why is this request (or response) being sent?
Useful in many works: ISUP/SIP mapping, in manyfolks (precondition failure, unacceptable here), HERFP, 3pcc.
Jonathan: Throw in another use: in the event that you fork the request to a bunch of phones and one of them picks up. The proxy generates CANCEL. The reason for CANCEL is not because the user hung up, but because 1 of N answered.
Rohan: Lot of overlap in the reqs that generated this document and request history.
Eric Burger: This is H.450 all over again.
Jonathan R: Don't we have an enumerated list of response code in the bis already? This is exactly that, and then some.
Comment: we have one address space for responses, and we have just added one more with the Reason header. Has a kitchen-sink feeling to it.
Henning: The motivation was exactly to prevent reinventing the same thing everytime. We are not adding new error classes that will have to be percolated to all existing implementation. This is a fine grained status code which is there if you need it. Example: Q.850 error code will not be pertinent to many implementations, but to the one that it is pertinent to, it can use it without too much perturbation.
Brian Rosen: What do we do now? 2 possibilities: crisp set of reqs, which are clear and this is a resonable solution. Or we do not have a crisp set of reqs. We need to determine this first. Lot of discussion on if this does or does not solve the job. But do we know what the job is? Should we push this back into sipping and generate a req document? Those who think we have a sensible set of reqs and we can move forward? Those who need more reqs? [The hum level was 50-50, no consensus by humming on if we have the reqs captured right.]
Dave Oran: Need hum on slightly different -- do we get involved in reqs that requires identity (being able to communicate why you are sending it to this particular party).
Brian Rosen: That is a reasonable suggestion -- so considered. We will get the reqs out before Yokohama and bring the solution out before then. Those of you who hummed against it should participate in the list when we discuss this on it.
Fleming Andreson, SIP Extensions for Media Authorization. draft-ietf-sip-call-auth-04.txt :
Changes: Category is informational -- Header is now P-Media-Authorization. Applicability statement about appropriate use (SIP Proxy and Policy Server (PDP) must belong to the same domain) Updated rules about when to add a P-Media-Authorization header. Additional security considerations -- don't encrypt message bodies (proxies need to examine them).
Open issues: None known (authors list need to be trimmed), currently in WGLC.
Jonathan: I will send you some minor reviews. More look-see needed in the security section. This token is about media authorization -- authorization follows authentication. DOes the I-D point out this issue?
Fleming: You do not neccessarily need to authenticate before authorization. Some entity has been given an authorization token to access some resource.
Jonathan: More discussion maybe needed on the security section -- you are
giving a token to a party that you may not have authenticated. If that is
your model, fine; a couple of sentences would probably suffice in the I-D.
Brian Rosen: The WGLC is going to get over, if anyone wants to raise more issues please do so. It fills the needs, even though it has a lot of limits. LC be it, we will move forward.
Ben Campbell, SIP Extensions for IM :
-05 draft; recent changes -- remove CPIM mapping to separate draft. Would like to include in 3rd bundle to IESG.
Highlights - sends IM; does not initiate a dialog, does not discuss message sessions; actual message in bodies.
Open issues: No recent discussions. Needs minor editorial changes (forking, threading -- couple of sentences). Anything else? Is it ready for LC? One more revision -- no change in substance, more editorial.
Brian Rosen: Ok, as soon as you have the revision, we will post it as LC.
Brian Rosen: Administering this list is no fun -- people forward their email to accounts that consistently run over quota. The list is setup so that only subscribers can post.
21:29 CST - WG adjourned.