message sessions
------------------

Lunch time conversations:
- Authentication in msrp, aki suggestion using existing thing like sasl.
- jonathan: used strickly for client authentication. Not clear why it buys you if you just want to use digest.
- wait until jon gets back. tackle again in the afternoon
- might mean less specification work by using sasl.
- depends on if digest is enough or not. do we want to extend security later or is digest enough?
- agreed that digest is enough for now.

Absrtact 
- it sucks. re-write.

Document splitting
- should msrp and sdp defitions: should they be in the same draft?
- keith: 2 indenpendant scopes in the abstract and therefore should be in 2 diff docs.
- jonathan favours one document.
- conclusion: try to last call this document in mmusic wg as well as simple wg.

CMS usage:
- need to say more about how key material is transferred.
- srtp
- Robert action: need cms expert to give opinion
- Jonahtan: why not use s/mime? no good answer.

-Do we need to say more about use of symmetric crypto? need security review here. Risk if we can't do it with CMS.
- conlusion: use s/mime instead of cms. check if symmertic keying is possilbe, if not postpose symmetric stuff for later.

Scalability:
- it is reduced by not allowing shared connections. Comment was that if this is not allowed, we're not much better than page mode.
- Do we need to talk more about scalability issue in draft?
- Adam: no more than sip does.
- Jonathan: what counter proposal? none.
- Ben: propose do nothing other than adding text talking about discouraging the use of relays.
- Ben: cullin commented why we don't use beep?
- j: does it really solve the problem? ben doesn't know.
- robert: capture in the document discussion from the list why we don't have connection sharing and the impact of doing connection sharing. Agreed.

Default port:
- j: need default port, for eg: firewall config.
- possibility to have a recommended port but nothing to do with protocol. An IANA registered port. Agreed.
- j: need SRV for bind, not visit.
- ben: what about visit? if msrp uri did not have a port? do we use SRV.
- j: still thinks its not useful.
- ben: pprefer to have same procedure for bind and visit.
- Adam: make it a should to include port. There is a situation where there is an msrp bus.
- j: agree, so it might be possilbe to still get address with no port, so in this case you need to do SRV.
-> go with SHOULD.
- default port agian: 
- port for TLS. If we decide to use 1 default port for tcp and tcp over tls, then we have to create a new method for tls.

- if i'm using msrps then i must a start tls first. if I don't, the relay can still fail my bind and visit saying that he wants me to use tls.
- on bind, if client msrps uri, then start tls first. if it has msrp, its tries bind with that. relay may reject that asking for upgrade to tls.
- relay must not create an msrps uri on bind not using tls.
- requiring tls is not good for peer-to-peer case, that's why we don't mandate tls.
- should we make it a SHOULD to use tls with relay? no.
- adam will reseach if we can sniff the tls HELLO to see if we can do without start tls.

Discovering need for relay:
- do we need a way to discover the need for a relay?
- discover using SRV?
- agreed not to discuss this in draft and leave text as is.

Timer values:
- soft state expiration. Transaction timeouts.
- need suggested values.
- is there a risk that one side thinks he's in session and the other is not. answer is that this is true for all protocols. one side wil notice and tear the session down.
- suggestion that timer starts when data stops. This fixes the problem of sending large messages while a large message is being sent
- need to go through an exercise to decide a concrete timer value and use it.

Naming of BIND
- keep it

Hosting requirements
- do we need to determine must-support requirements for the various host scenarios?

What is a tuple?

- issue: tuples represent media, they should also represent devices.
- issue: tuple represents a point of communication.
- issue: 
- j suggestion: need to put some slides summarising discussions to bring everyone up to speed. do that by tomorrow morning.



Partial Notification:
- require-headaer??? you can use q-value in accept header as indidcation, but the server still has the final decision.

- what is the exact requirement? its a SHOULD.
- q-value is good enough.
- some potential for reuse of the xcap event notification content-type for this purpose.