Back to SIP Notes and Minutes IETF 71
IETF-71 SIP WG Thursday, March 13, 2008 9:00-11:30 reported b Bob Penfield draft-dotson-mutual-auth-01 - from CableLabs - need liaison? - redocumentation of HTTP header (which is not used) - need further discussion on mailing list - make consensus call shortly after meeting session-policy-framework - some desire for alternative policy protocol (e.g. HTTP) - issue not understood by many people - needs more discussion on the list - default is to go forward as is (no alternative policy protocol) sipping-199-04 - passed from SIPPING - intend to add to charter sip-outbound-12 - reached agreement on keep alive (clarifying text) - so UA knows that it can send keep alive when not using outbound registration - Jiri - why have keep alive in this document at all? - Minor Issue: Flow-Timer (in or out)? - no consensus to remove. It stays subnot-etags - Author to add explanatory paragraph eliminating ambiguity on "version" sip-info-events - question? a) INFO events b) ban INFO Cullen wants discussion before decision no consensus, no time to discuss today, no decision yet. Cullen - we could add a milestone for this JR - need to discuss this. Suggests conference call sip-location-conveyance - awaiting requirements for "routing handling" from GEOPRIV - doc will stay as is if we don't get those reqs. Essential Corrections - what is structure? a) standalone doc b) "differences" with published RFC - implementers find complete text most useful, but like "differences" - should we have both for all docs? - do on a case-by-case basis - need comments on the list for structure - do WGLC for invfix. Dan Wing - Requirements for Media Security - R15 (start with RTP & upgrade to SRTP), was previously removed - R15 will be added back in - Moving forward: - publish results from RTPSEC BOF (publish now) - or add changes for/from 3GPP, call-recording, transcoding, SBC identity problem * Consensus to Publish Now(with R15) and do future requirements in new documents. UA Initiated Privacy: Mayumi Munakata - Anonymous URI in From 1) 3261 = anonymous@anoymous.invalid 2) 4474 = anonymous@<user-domain> 3) new = use temporary GRUU #3 could be used as temporary pseudonym Rendering #3 would be bad Possibilities: a) document all 3 and when to use them b) narrow down * About 50/50. Need use cases to determine if #3 is needed Need use cases to know when and how to use each mechanism. #3 best handled by 3rd party service (not the UA). Conclusion: drop #3 (from this draft). keep #1 and #2. (with #2 as default?) domain-certs and sip-eku: Vijay Gurbani - Subject-Alt-Name (CAs do not provide it in certs) - draft says cert MUST have SAN - commercial CAs won't add it for relatively few certs * EKR to send text - add explanation why wildcards not allowed Chairs & ADs will decide if drafts are to be merged or not Request URI and Parameters to UA by Proxy: Christer Holmberg - History-Info could be used instead of new Target header Clear there is no consensus on either Target or UA-Loose-Route. Chairs and ADs will discuss best way to proceed. Identity Requirements for E.164 and SBCs: John Elwell Questions from slides - lots of discussion - no conclusions - take it to the list