Done | | Server Features Negotiation submitted to IESG |
Done | | Complete IESG requested fixes to provrel and servfeat |
Done | | Revised proposed standard version of SIP (2543bis)
submitted to IESG |
Done | | SIP Events specification to IESG |
Done | | The UPDATE Method submitted for Proposed Standard |
Done | | SIP extensions for media authorization (call-auth)
submitted as Informational |
Done | | Preconditions extensions (manyfolks) spec to IESG |
Done | | SIP Privacy specification to IESG |
Done | | SIP Privacy and Security Requirements to IESG |
Done | | The MESSAGE Method submitted for Proposed Standard |
Done | | The Replaces Header submitted for Proposed Standard |
Done | | Refer spec to IESG |
Done | | SIP NAT extension submitted to IESG |
Done | | SIP over SCTP specification and applicability statement |
Jan 03 | | Guidelines for Authors of SIP extensions submitted as
Informational |
Done | | Mechanism for Content Indirection in SIP submitted to IESG
for Proposed Standard |
Done | | The SIP Referred-By Header submitted to IESG for Proposed
Standard |
Feb 03 | | Session Timer spec, revised to IESG |
Feb 03 | | Caller preferences specification submitted to IESG |
Apr 03 | | The SIP Join Header submitted to IESG for Proposed Standard |
Apr 03 | | Submit SIP Identity documents to IESG for Proposed Standard |
Jul 03 | | MIB spec to IESG |
Jul 03 | | Review WG status (consider closing) and/or submit a future
milestones plan to IESG |
Minutes, SIPWG IETF57
Recorded by Alan Johnston (alan.johnston@mci.com)
Edited by Dean Willis (dean.willis@softarmor.com)
Revised 17Jul2003
----------------------------------------
----------------------------------------
Meeting July 16, 2003, 0900
Start
-------
Meeting called to order by chairs.
Proposed agenda reviewed and accepted.
Announcement: Jon Peterson has retired as SIP co-chair.
Brian Rosen volunteered as chat room moderator.
Alan Johnston volunteered as scribe.
Status of Drafts - Chairs
---------------------------------
New Pubs: RFC 3515 REFER published
MIB: Volunteers to review a section of MIB: Orit Levin, Mary Barnes,
Cullen Jennings, and Kent (Rohan has his info). Rohan will assign some more
volunteers.
congest-safe: Proposal for author to remove UDP kludge. No
objections or discussion.
PUBLISH - Aki Niemi
------------------------------
Open Issue: collision recovery. Proposed solution: query principle, may
subscribe to package. No objections or discussion.
Open Issue: PUBLISH and dialogs. Proposed solution: add text about
dialogs, discourage reuse. No objections or discussion.
Open Issue: atomicity. Proposed solution: relax restriction about
overlapping requests.
Comment: Go with a simpler model - all tuples are independent. Solve
using composition and authorization instead of publication. Or, most
recent publisher overrides any others.
Comment: Agree with comment. Don't reinvent Webdav. Don't make
endpoint behavior too complex.
Comment: Agree with comment that this is an authorization problem.
Comment: Not clear we can relax overlap with congestion issues.
Conclusion: Author will take to the list for more discussion.
Resource Priority - Henning Schulzrinne
-------------------------------------------------------
Issue: error handling. Proposed solution: 503 or 403 or 417 (Unknown
Resource Priority - only if Require is used. No objections or
discussion.
Believed to be ready for WGLC
Comment: Pointers to name spaces are in draft.
Comment: Role based authorization is still moving forward.
Volunteers to review the next draft: Paul Kyzivat, Ben Campbell
Caller Prefs - Jonathan Rosenberg
-----------------------------------------------
Issue in Callee Caps - URI-user and URI-domain - duplication:
Suggested Use a Device ID (Contact URI attribute) instead? No
conclusion in this discussion.
Comment: Device ID is interesting, but could be overloaded. Should
recommend GRUU for attended transfer.
Comment: Expiration of device ID is unpredictable.
Conclusion: Quick list consensus on adding device ID. Recommend GRUU
instead for transfer case.
Caller Prefs
Comment: Enumeration is better
Open Issue: redirection - RFC 3261 proxy merging q-values is broken.
Proposal: include text saying this.
Question: Do we need to mandate this? Questioner will send a short use
case to mailing list.
Open Issue: lost use cases due to changes.
Comment: This is a feature.
Comment: Can be done with multiple requests.
Conclusion: no changes needed.
Open Issues in Use Cases: No discussion.
Comment: Does basing on RFC 2533 provide any value?
Comment: Should RFC 2533 reference just be an informational
reference?
SIP Identity - Jon Peterson
-------------------------------------
Topic: AIB
No issues or comments.
Topic: AES and S/MIME
Question: Should we redo S/MIME examples in RFC 3261?
Proposal: Cullen Jennings could do some examples.
Comment: Base-64 encoding issue causes interoperability problems.
(Binary encoding is better)
Comment: No commercial SIP stacks support S/MIME and TLS.
Comment: There were 2 implementations of S/MIME at last SIPit.
History Info - Mary Barnes
-------------------------------------
Open Issue: Index. Proposal: Make it mandatory and clarify loose
routing behavior.
Open Issue: Internal Retargeting. Proposal: Include some normative text and
examples.
Open Issue: Privacy. Proposal: Add text.
Comment: Draft needs major clarification on privacy, redirection,
backwards compatibility, others. Will discuss on list.
Comment: Include in security section - this header solves a useful
problem that a requestor could verify that appropriate proxies have
retargeted a request.
Conclusion: Much more work needed.
Securing SIP Identity Headers - Mary Barnes
----------------------------------------
----------------------
(SIPPING draft but discussed here for convenience)
Comment: Question on question not solution. Do we need to do this?
Comment: This is a type of middle-to-end security problem. We need to
solve this problem.
Comment: If we redid Proxy-Auth header, we would use a body instead of a
header.
Parameter Registry - Gonzalo Camarillo
--------------------------------------------------------
Open Issue: Which URI parameters should be registered?
Comment: Do we want p-parameters?
Comment: Lets not make the same mistake twice.
Comment: Want to increase interoperability and avoid collisions.
Comment: To prevent conflicts during Internet-Draft stage, should use this
registry.
Comment: C language analogy -- this is like requiring C developers to go
back to Standard C committee and register every variable name they use as a
language keyword. The registry could be flooded with requests. Propose
that we should only register URI parameters that are global in nature.
Comment: Have informal non-IANA registry instead (webpage)
Comment: Should do the same thing for parameters (headers and URIs) as
headers.
Comment: Similar to standardization of headers across protocols effort.
Conclusion: A Hum was taken which supported the creation of an IANA
registry for parameters defined by RFCs. No consensus on the rest of the
issue - more list discussion needed.
Connection Reuse - Rohan Mahy
---------------------------------------------
Open Issue: Clarity on which is original and which is alias.
Open Issue: Security - explaining Mutual TLS and digest
A Humm was taken which supported that people care about the work.
A Humm was taken which supported that this mechanism is reasonable.
Comment: Need to describe how to handle when multiple parties claim the
same alias (10.1.1.1).
Conclusion: A Humm was taken which supported that the chairs request a
charter modification to adopt as a WG item.
SIP Security and S/MIME - Cullen Jennings
----------------------------------------
--------------------
Comment: Mechanism could be used for certificate or raw keys.
Comment: Identity work avoided UAS having to do any PKI operation.
Identity document also only identifies the domain,
not the individual user.
Question: Does this work in both ways? Answer: Yes, but not exactly.
Many more comments until we ran out of time.
Hum taken on interest of working group in solving this problem. Strong
interest indicated.
Conclusion: The WG will continue discussion of this topic.
|