Notes, SIMPLE First Session, IETF61

Reported by Dean Willis

Agenda bashed.

Status of various drafts presented on slides. Noted that "is

composing" is in RFCED queue, not IESG queue.

Topic: MSRP

------------------------------------------------------------

Discussion lead by Ben Campbell

Slides presented.

Changes since last pub and dependencies reviewed.

Changes from security review:

Added applicability statement around usage with rendezvous/negotiation

protocols.

Mapping of "im:" URIs. This needs to be in a separate

document. Dicussion ensued as to whether MSRP blocks on this

document. The general consensus is that it does not, as MSRP never

sees an "im:" URL (this would be a rendezvous dependency).

Security review suggested reintegrating core and relay

drafts. Consensus seems to be to resist that suggestion. Suggested

that the full security story needs to be in one of the two drafts.

Previous deaft missed RFC 3682 Application Considerations on usage of

CPIM headers. This has been clarified.

Open issues:

"?" Parameter Syntax: Proposed that this be added to the next

rev. Discussion: Cullen has a concern that this may break the security

model and will review offline with author to ascertain.

Overlapping Chunks: Concluded to recommend that most recently received

chunk wins unless the application domain dictates otherwise. No

arguments raised against proposal.

Report handling: Consensus among authors that current draft is

underspecified. Proposed that negative reports be "per chunk" and new

incremental values for Report-Success (as well as per-message) be

permitted. No argument raised against proposal. Further: Relaible

delivery requires positive Report-Success or incremental,

Report-Failure allows rapid failure detection (along with normal

failure timeouts). This would require requesting both success and

failure reports at session setup. No argument against

proposal. Further: Proposed that spurious reports be silently

dropped. No arguments araised against proposal.

Discussion: Does Section 8 (O/A, SDP Ext.) need to be reviewed

elsewhere? This includes some a-line attributes and fmt, and that

sdp-new requires a more detailed registration process. We may also

need to register TCP as a transport. Task: Chairs will work it out

with other chairs and ADs. Note: TCP has been registered as part of

comedia.

Discussion: Have there been any implementations? One report of

preliminary implementation experience, on which the developers had

"serious heartburn", primarily around the abnf that was supposedly

fixed in this release. One other concern was raised around handling

the closing -- given the structure, one can't detect flow end strictly

by ABNF, and list consensus was to stay with this.

Discussion: Is the flow control built into MSRP justifiable? If so,

then we need a relay push-back capability to handle

buffer-overflows. This interacts with "many-flows onto one-TCP"

plexing, and providing reordering of chunks. Argued that reordering is

required anyhow, so this is no added complexity. Conclusion is that

the current text seems consistent with our understanding of

requirements.

Discussion: Similar SDP-ish stuff is being described in BFSCP. Should

we unify? Concluded that the authors will get together and discuss.

Further discussion on implementation: Implementors seem to be

deferring deployment until the RFC is published. This view is

supported from experience reported in 3GPP about their attempt to use

MSRP.

Topic: MSRP Relay

--------------------------------------------------

Discussion led by Cullen Jennings

Slides Presented

Noted that we need one example in text. Other than that, there have

been no comments on-list.

Poll: Who is planning to implement MSRP base? (Many, app. 40). Who is

planning to implement MSRP relay (much smaller, app. 9).

Poll: Who plans to read and comment during last call (very many, 1/3

of room).

Topc: Presence Rules

---------------------------------------------------

Discussion led by Jonathan Rosenberg

Slides presented.

Slides review changes from previous version.

Discussion of anoymous: Seems to be a desire to differentiate an

"unknown user" from a "user authenticated to the network who prefers

not to disclose". Is a non-authenticated "From" identity not the same

as anonymous? How does this relate to Caller IDs "Anonymous" vs

"Unavailable"? Is there a need to present anything relative to the

strength of authentication used? Proposed: no plan to add an

"authenticated" condition. Unauthenticated identities will be

considered comparable to "unknown". Local policy will determine

whether any specific authentication technique counts as

"authenticated", and techniques below this threshold would be counted

as "unknown".

Proposed that we may need a way to match "any" identity in a rule.

More discussion.

New proposal: Delete special treatment "for authenticated but

anonymous" and consider all non-revealing identities "unknown".

More discussion.

Point: Unauthenticated should NEVER receive more information than

"authenticated but anonymous".

Editor: Why does nobody seem to understand that this is a two-axis

system? Axis 1 is "Authenticated vs. Unauthenticated", and axis 2 is

"Presenting vs Not Presenting Identity", and that decisions need to be

made for at least three of the four resulting tuples?

No conclusion noted.

Changes since last rev reviewed.

Several issues drew brief discussion with some suggestions of

discussing offline.

Discsussion returned to identity, the uncertain, and the unknown. The

result was unclear.