Minutes, SIP WG, IETF 59
Reported by Ben Campbell
Edited by Dean Willis
Chairs: Status and Opening Comments
Changes:
- No new RFCs, 6 docs post last call, 3 in ed queue
- Security ad-hoc to discuss discuses on auth-id
- IETF last call 8 more, wglc on resource priority, almost closed.
To Do: Chairs: Conclude on resource
priorty.
Group recognized Henry Sinnreich as the "Godfather of SIP" and
applauded.
Status for app interaction:
Moved to SIP. integrated normative lang for GRUU. Need to harmonize
with KPML. Nts review after KPML alignment. Call for 4-6 reviewers.
Connection Reuse:
More explanatory text. Please read to make sure it makes sense.
Identity:
Author wants to replace this with generic mech for 3rd party mods and
assertions. Proposed to merge with other requirements into a generic
mechanism if possible before San Diego. Ad-hoc on Tuesday.
Cullen requests reviews on draft-jennings-sip-sec-flows-01.
Mary Barnes: Request History Mechanism.
Changes
- Editorial nits
- Merged sipping wg reqs into solution draft.
- Removed redirect server from ISSUER-req.
- Addied explicit privacy requirement for proxy to maintain privacy
asssociated withe captured r-uri.
- Clarified syntax. Removed compact form.
- Added application consideration summary section. Added more text
on what to do if history is not available.
Issue: Privacy:
Proposed adding filed to tag HI entries that are added when privacy is
imposed.
Issue Limitation on number of entries?
Options: Pruning mechanism, or just leave to endpoints. Needs more
email discussion.
Cocnlusion: No apparent support for
limit.
Next Steps:
- More email feedback on open issues -- Text requested.
- Update flows.
- Dependency on the e2m security body manipulation.
- Discussion on proxy manipulation of bodies--will be discussed in
ad hoc.
Question: Any implementers want to comment on limit?
(no response.)
Cullen Jennings: Voicemail URI
Changed to use reason header, rather than separate one.
Issue: Should this be a parameter, or a header?
Conclusion: Support for parameter.
Issue: Should we do history instead?
- Cullen proposed yes.
- Lots of semantics discussion.
- Mixed support for using history info.
- Suggestion that VM service parameters are different than generic
reason header.
Conclusion: Remove reason header, put
explicit service invocation parameters.
Question: Anyone plan to implement?
Very few responses. (History being held on whether URI is better.) Need
to design something soon.
Question: Can history and voicemail can be complementary.
Discussion indicates yes -- they are different mechanisms that can
sometimes, but not always, be used to solve similar problems.
Question: on whether voicemail URIs should be standard,
informational, or abandoned.
Conclusion: No consensus on whether
this should be wg item or not. Consensus not to make it an individual
effort.
Culleng Jennings: Binary Encoding
Bodies use content transfer encoding. 3261 gives no guidance on what
sort of encoding. Proposal to change it so say you SHOULD use binary,
but need to be able to receive any.
Question: What about indirect content?
Discussion indicates that indirect content woul be contyrolled by the
rules of whatever protocol and data format is being indirected to.
Question: Do we have base64 in SIP specs we need to expunge?
Robert volunteered to help editors change examples to show binary
encoding, using scripts he used for the torture test draft.
Question: Why couldn't this be on the list.
No discussion, just muttering.
Conclusion: Only binary, no
requirement to receive non-binary. Will go into errata in a prominent
way.
Hisham Khartabil: Policy URI and purpose
Issues: proposal to make purpose uri specific for conference
policy, rather than policy in general. conf-policy-uri rather than
policy-uri.
Conclusion: accept proposal.
Issue: Should we set up an IANA registry for purpose parameter?
Discussion on whether iana registry is just for conflict avoidance, or
whether it is a central point to document things.
Conclusion: No registry.
Hisham: authentication issue skipped for time.
Jon Peterson pointed out RotK one big at the Academy award.
Robert Sparks : Non-invite Transactions
Changes:
Split in 3--analysis, agreed changes, controversial changes.
Open issue: draft says SHOULD cache unreachable destinations. Is
this enough?
Failover for next attempt will not happen if not chached. propose
making this MUST.
Argument on what should means.
Conclusion: none
Issue: draft says time-to-live of cache should be short. Can we
specifiy a concrete duration?
We do have a concrete duration if retry-after is specified. Proposal:
keep current text.
Conclusion: none.
Next Steps:
Will do the stuff on the last slide
Cullen Jennings: GRUUS and
Instance Identifiers Requirements
Cullen described some use cases and requirements: client generated,
stable across reboot, unique, multiple allowed per host, possible to
know identifier without taking phone out of box.
Conclusions: No clear conclusions.
Jonathan Rosenberg: GRUU Mechanism and Device ID
Changes:
listed on slide.
Issue: Registration Conflict.
Crash/reboot may cause two contacts with same instance ID.
Options: requests for gruu fork (with a bad fork), registrar should
reject registration (telling client to query and delete), registrar
should delete old registration.
Proposal: registrar rejects, client then deletes. New response
code a good idea.
Conclusion: No consensus. Need to
think about performance impact on registrar.
Issue: should this be a caller prefs param?
Currently it is a calle capability parameter.
Proposed: Keep current, add text advising against using with
accept/reject contact. Use GRUU instead.
Conclusion: Accept proposal.
Issue: Format of instance ID
Is it a URN? do we specify computation?
Proposal: Do not specify computation, must be formatted as quoted
string, merely require temporal and spatial uniqueness.
Comments: hard to guarantee global uniqueness in quoted strings without
specifying computation. URNs may be better. Does privacy apply?
Conclusions: No consensus, need to
work on this some more?
Issue: GRID usage outside of GRUU. Should this be a generic URI
parameter?
GRID survives proxy translations. Is a form of sub-addressing. Should
this be a generic URI parameter?
Proposal: generic URI parameter. Can be applied to other mechanisms.
Only makes sense in the context of URIs that represent an instance.
Conclusions: No comments. Does this
mean we accept it?
Issue: Document Other uses of GRUU here?
Proposal: No, specific problem.
Conclusion: No comments. assume
accepted.