SIMPLE Notes

3/8/2005 0900-1130

Recorded by Dean Willis

Topic: MSRP

Ben Campbell

Slides presented.

Changes since last version reviewed.

Comment: Additional registration may be needed for SDP content type when TLS is to be used, perhaps msrp/tcp/tls.

Issue: Overlapping data

General consensus noted on suggested approach to clarifying wording as non-normative, with example of "if already rendered" to be used.

Proposed that document is ready for working group last call

Topic: MSRP Relay

Cullen Jennings

Slides presented.

Changes since last version reviewed.

Discussed whether basic authentication may leak data when the TLS connection is terminated through a hotel proxy, so this may need discussion in the security considerations.

Question: Should stateless relay implementation (in appendix A) stay? Proposed that if we want to keep the text, we might want to move it to a separate informational draft. Also proposed that we simply delete the appendix. Consensus to delete appendix A reported.

Question: What else needs to be resolved before the document will be ready for last call? Need to clarify some base draft text on handling for new methods.

Topic: MSRP Conferences

Miguel-Angel Garcia Martín

Slides presented.

Comment: It's possible that we might discover from XCON that extensions are needed to loots of things to make them conference right. Once we've started putting distribution lists into bodies, we may not need the distsend method and distribution header. Suggested that it would be better to have a general mechanism instead of extending each protocol. Extended discussion followed.

Comment: We need a way to manage the overlap between this work in the three working groups that are discussing it -- xcon, simple, and sipping.

Comment: We need more clarity on what is happening in xcon, such as subsets of conferences, before we can really do proper conferencing extensions to MSRP.

Comment: requirements should be taken into xcon and handled there, rather than being piecemealed in each protocol working group. The requirements in this doc seem reasonable and should be taken to xcon.

Comment: There seem to be huge disconnects in the meaning of "nickname" to different people in this discussion.

Chair comment: nicknames are NOT a SIMPLE problem. Where should they live?

Question on requirements: Since ordered delivery is a requirement, is there a requirement that if some recipient does not receive a message, should all other recipients stop receiving messages? Further discussion is needed.

Proposed that we assemble a team to determine how to do nicknames across the whole SIPpish community.

Comment: There seems to be a real requirement to communicate message sequencing, if not to assure in-order delivery. We should carefully reword this to be solvable.

Comment: Any attempt to define new identifiers raises many questions, including scope, membership of namespace, identity assertion, etc.

Conclusion: we will discuss further and see if some approach comes out.

Topic XML Patch Operations

Jari Urpalienen

Slides presented.

Changes since last version reviewed.

Comments: Very concerned about a scope that appears to be defined as an alternative to xcap. Extended discussion followed.

Poll: How many people read and understood this draft? A surprisingly large number.

Comment: Document DOES seem to solve the problems that it targeted.

Comment: We seem to be trying to trying to reinvent document transformation. Debate followed, with a consensus resulting that "patching" is different from "transforming".

Comment: It seems like we have a bunch of working groups and outside orgs coming up with diff formats for xml. This suggests that we should, a most, do something very simple here (and Rohan has already suggested that xcap-diff is already too complicated). Or we could go work on the general problem.

Comment: We don't need yet another way to modify documents. Also trying to implement this on top of a system that already uses xcap requires complex modeling.

Comment: You probably want to look at xupdate, which is W3C work to do the same thing.

Comment: XCAP is a good general purpose mechanism. If we were starting over and just wanting to do buddy list management, something simpler would probably suffice.

Chair comment: When we asked Jari to do this, we were asking for a solution to the first bullet -- resolving the different diff mechanisms we were already using. We got something more general. Question: Do we as a group wish to do a targeted solution for XCAP, or do something more general?

Comment: For someone who is just worried about XCAP, any generalized mechanism requires trying to transform a diff set into a series of xcap operations.

Comment: There is a sourceforge project ongoing to do an xmldiff solutiuon that is nearing publication.

Proposed: If we do anything, it should be xcap specific.

Chair comment: A general solution would probably be outside of our charter. Something that is specific to SIMPLE would be in our scope.

Comment: We need to consider pidf-diff as well as xcap-diff.

Chair Conclusion: It does not seem that this specific proposal (document under discussion) does not represent the path the group wishes to pursue. We will have to debate on list what the correct path is.

Comment: Though sympathetic to the comments raised, nobody has suggested that this solution doesn't work. It would be a shame to dither for six months, then come back to this solution.

Poll: If you think we need an advanced patch solution (general): Small response. If you think a narrow scope solution would be better: larger response. Undecided: larger response. Conclusion: inconclusive, more discussion needed on list.

Topic: Policy Capabilities

Jonathan Rosenberg

Slides presented

Poll: Who read? (reasonably small number).

Question: Is the lack of comments an indication of consensus, or apathy?

Poll: Should we adopt these two documents as a working group effort and go forward? Consensus reported to proceed with adoption.

Topic: User Agent Capability Extension to PIDF

Aki Niemi

Slides presented.

Comment: doing a merge of two documents with conflicting priority value ranges is difficult. for example, if one document has "<4" and another has ">7", how do we compose them? Discussion followed, and somebody needs to go look at callee-caps and see what it can express (integer, restricted to the values of the priority header field, RFC 3840).

Topic: Presence Processing Model

Jonathan Rosenberg

Slides presented.

Issue #1: composing unknown attributes. No arguments to proposal.

Issue #2: overrides. Rohan suggests that he has issues, but that they could not be resolved with 15 minutes of discussion.

conclusion: Author will take issues to list as individual topics.