SIP for Instant Messaging and Presence Leveraging Extensions WG (simple)

Monday, August 2 at 1300-1500

=============================

CHAIRS: Hisham Khartabil <hisham.khartabil@nokia.com>

Robert Sparks <rsparks@dynamicsoft.com>

AGENDA:

13:00-13:05 Agenda Bashing, Chairs Report

§ IMPP documents are in AUTH-48 – should be published really soon

§ Filter has been through WGLC, please send comments

§ XCAP base draft and PIDF manipulation draft in WGLC now

§ Want to send MSRP base and relay drafts to IESG back-to-back

§

13:05-14:15 MSRP Base (Ben Campbell)

§ Version 07 is major re-write of this document

§ Going for readability and fixing “cut-and-paste-itis”

§ Changes are report handling, framing, chunk handling,

eliminating VISIT method, transport and TLS, and adding max-size to media

§ Two headers for report selection (Report-Success and

Report-Failure) – Report-Failure needed to accommodate relay operation

§ Chunking very intrinsic to MSRP, so promoted to a Byte-Range

header

§ Recommended chunking at 2KB boundaries

§ VISIT semantics became almost identical to SEND, so replaced

with an initial SEND request

§ Transport parameter added (TCP is only defined value, but

would accommodate TLS in future)

§ Max-Size refers to complete message content – entire message body

§ Chunking – Adam proposed two flags on the list – allow an

additional flag that says “last chunk, I’m abandoning this message”? – OK

§ If you have real numbers in byte range numbers, header should

reflect this – but there’s an issue with interrupting streaming media –

require “stars” as last byte in byte-range header if the message is

bigger than 2KB? - OK

§ What certificate identities do you present for TLS? Relay

draft doesn’t have quite the same language as HTTP-S – should copy that

language exactly. Cullen – should match what we did with SIP-S. Jon –

does the SRV record match the URI? That’s the important part.

§ Open issues

§ Transaction responses are tied to error reports - should they

be separated? Proposal – leave tied together –

§ Extensibility – we’re not going to have a version number, we

need to document our decision not to have version numbers – non-backward

compatible extensions become new protocols instead

§ Max-size will refer to all media types, not per-media type

§ Page mode vs session mode – need to give guidance, but not in

this document. SIMPLE architecture? Where?

§ How to slow down packet rates? No other way than slowing down

request rates.

§ Is DSN still required? We can send reports, don’t need

human-readable DSNs. Still allowed – it’s a body part - but what’s the

guidance here? Is anything required beyond what people can Accept: today?

§ Need to map MSRP headers to SIP headers to avoid confusion.

§ Need to make sure that focus won’t be inserting identities –

we rejected this previously, and it’s creeping back in – this doesn’t

work for anonymous participants – but can’t they provide their own

anonymous identities? Need to map what they provide to a participant

roster, though. Need to take this offline, with two concrete proposals.

§ Need to be clear about headers that are end-to-end vs

hop-by-hop – we blew this in HTTP and inherited the problem into SIP –

can we be smarter?

§ Ready for WGLC of next draft, in a week or so? Please send

open issues ASAP.

14:15-15:00 MSRP Relay (Rohan Mahy, Cullen Jennings)

§ Last-nanosecond editing pass doesn’t quite align with the base

spec (which is now complete enough for the relay functions) – need one

more pass to complete this.

§ SEND and AUTH responses are end-to-end

§ Client which needs multiple relays sends AUTH to each one,

inside out, and relay uses complete path to authorize requests

§ Relay to Relay is always TLS with mutual authentication,

client to its relay is always TLC with Digest, foreign relay to client

can be either TCP or TLS.

§ Relays can re-chunk, and must be able to interrupt chunks

bigger than 2 KB.

§ Refreshing AUTHs – suggesting periodic new AUTHs, but need to

work out details – but WG chose not to go this way, a long time ago –

can we remember why? Maybe because that was end-to-end and this is

relay-to-relay. Maybe OK.

§ Need to catch up with base protocol, make document

self-consistent. What other changes are needed?

Rohan – how to do AUTHs that aren’t one-AUTH-per-session?

§ This is like base GRUUs – if people know my relay MSRP URI,

they can pass out that URI to their friends and I’ll relay anything they

send using that URI.

§ Talking with Ted about security aspects of this – sufficiently

complicated to require security assistance in getting this right.

§ What does “passing out” mean? Does it matter if eavesdroppers

hear the URI?

§ Does “time-limited” help? The URI doesn’t last forever.