JR: based on early simulation work by the overload design team
Led by Francois Audet
Issue: Error Codes
currently two error codes
Proposal is to have one error code with Allow-URI and Require-URI header
JR: already have 416 error code, could use with Allow-URI/Require-URI
FA: 3261 dictates 416 behavior
Adam: 416 means I don't understand the scheme, 418 means I understand it, but it is not allowed.
JonP: bothered by semantics of not allowing sips .. degrades security. Want more specific and targeted solution rather than general one
JR: what is the real meaning to "support" something. context defines reasons it support. its the same problem here with 416.
EKR: want a hard failure when cannot forward to UA because of sip/sips.
RM: think we can do this with 480. 416 when proxy does not support sips. use 480 because there are no contacts registered for the scheme.
JonP: agrees with Rohan (1st time in 4 or 5 years).
John Elwell: worried about overloading 480
JR: using 480 confusing for backward compatibility. do need something that is explicit. dont like EKR idea of using a string. do 416 or 418.
EKR: dont make it more convienent to downgrade security. peoples default behavior is to ignore the warnings. don't encourage
RM: use a Warning header that automata can use. using 480 would require more thought by implementor to automatically downdrage
JR: do we want to make it hard to do this (downgrade).
FA: agree with Rohan that if we hide it, people will be less likely to be stupid
JonP: semantiucs should be that there are no resources registered with that scheme
CONCLUSION: take it to the list, will have a conference call to resolve it
Issue: Record-Routing
Consensus to remove section 3.3.2
Led by Rohan Mahy
ISSUE: Flow Token Algorithm 1
Conclusion KEEP AS IS
Issue: keep-stun & keep-crlf
Proposal: change to a single 'keep' parameters
Christer: if i use IPSEC, do i still have to send STUN?
RM: it means the server supports it
Cullen(I): does not change any behavior. just changes the parameter name.
NO OBJECTIONS: change to 'keep'
Issue: Abuse of option tags
Adam pointed out that the spec violates all 5 rules of option tags
UA sends Supported:outbound
Registrar included Require:outbond in response indiating outbound was used
UA then places ";ob" parameter in Contact of requests it sends.
NO OBJECTIONS: fix 'outbound' option tag in this way
led by James Polk
Requires standards track RFC
Requirement two level namespace
Propose adding "-" to separate (e.g. "dns-00001.routine")
Joel Halpern: why do we need to standarize the "-"? If you really want to do this, you need to have a registry for the precedence domain. i.e. you must 'own' dns- to add dns-0001.
DECISION: remove '-' as a separator
Needs to become a WG document
WG Adoption? weak consensus in favor, no one opposed
Cullen(AD): will abide by chair decision
probably will go ahead with this
Is this document, the right direction? again, weak consensus, no one opposed
Led by James Polk
should RPH be in responses?
RM: get rid of table 2 (for all specs) at a convenient point
Joel H: needs to see better explaination as to the problems it solves - James will do that.
Issues:
WG Adoption? weak consensus (stronger than last time). no one opposes
Is this the right document? weak consensus. no one opposes
Led by Jonathan Rosenberg
Alternative proposed on the list:
JoelH: hard to know what is and when is it "retargeting".
Christer: P-CP-ID has been around a long time and has been implemented.
Dale: require that the proxy carries a given URI parameter when retargeting
Cullen(AD): P-CP-ID would need work and would need to be a standard track doc.
Ted Hardie: like e-mail faceted address problem. likes URI parameter. want to avoid 'local knowlege'
Robert Sparks: need to continue to address issues with re-targeting & routing
PaulK: if its a parameter, input & output both have to be a sip URI
John Elwell: would like to see written proposal of P-CP-ID
Poll: make decision now? or later when more documentation available? consensus to make it later when there is more documentation of the other solutions.
AndrewAllen: need to make sure changing P-CP-ID does not adversely affect IMS.
led by Gonzallo Camarillo
Clarifying how message bodies (multi-part) are handled
Change SHOULD for multi-part to MUST
Change SHOULD for multipart/alternative and multipart/mixed to MUST
Nested Body Parts
Do we fully support MIME or not?
a number of people say we should support MIME properly.
Applications-AD: profiling of the MIME spec is not acceptable
cannot win specifying things that are quality of implementation issues.
Conclusion: Gonzalo will update text and it will be discussed on the list
multipart/alternative
content-disposition
Content-Transfer-Encoding
415 Response Codes
References to body parts
Do we want to charter this area?
consensus to work in it.
Is this the base document?
consensus to adopt the document as a baseline
Back to SIP Notes and Minutes at IETF 69