[Sip] SIP Draft Minutes

[Dean Willis <[e-mail]>]

Draft minutes for the SIP meeting at IETF 59 are posted at:

http://www.softarmor.com/sipwg/meets/ietf59/notes/minutes-sip-ietf59.html" rel="nofollow">http://www.softarmor.com/sipwg/meets/ietf59/notes/minutes-sip-ietf59.html


Please respond with correction. I'm not sure we have the conclusion recorded correctly on at least one of the GRUU issues.

MHTML Follows.

Draft Minutes, SIP WG,  IETF 59

Reported by Ben Campbell
Edited by Dean Willis

---

Opening stuff

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: 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.