SIMPLE IETF 62 Meeting Minutes
Minutes - IETF 62
(thanks to Dean Willis and Chris Boulton)
Recorded by Dean Willis
Issue: Debate on "unknown" element for lists (like activities) -- "empty" vs
"null" Do we need to be able to distinguish between an empty element and a
Noted that we use the same syntax for both publication and notification. Should
we include discussion of the composition aspects of the schema?
Argued: We don't want to use the presence documents themselves as a statement
of policy on composition functions. If it tells the presence service how to do
something, it doesn't belong in the presence document.
Comment: Is this just a terminology issue: If we replace "unknown" with
"other", would that solve the problem?
Comment: it seems to be useful to have the ability to differentiate an explicit
assertion of neutral state vs a state about which no assertions are being made,
independent of the composition policy.
Poll: Should we include unknown elements at each enumeration? Rough consensus
in favor of inclusion.
Issue: Do we include source/type identification? This seems to be problematic
from an authorization perspective, and impossible to completely enumerate.
Proposed that we exclude source/type identification from the current effort.
plans are to release -06 immediately after IETF 62.
Presence Data Model
Changes since last rev reviewed.
Issue #1 Do we need an enumeration of services? A service registry has been
proposed. Author proposes not, that reach information suffices.
Comment: The reach information is useful and adequate to solve the problem.
Noted: Reach information is a child of tuple, not status. This needs to be
clearly stated in the document.
Comment: The examples need to be consistent with recommendations in callee-caps.
Note: Add discussion about the interpretation of non-existing data to data
model. Prescaps need to follow the callee-caps model.
Issue #2: Available IM, Not Audio
Do we need to address this in the data model? Author believes the current text
leaves the decision open.
Consensus to add to the data model words indicating that capabilities can
change, and to include example possibly based on Aki's example.
Debate point: Just because I'm busy for IM, it doesn't mean I can't receive IM.
Can we distinguish between capabilities and availabilities? Does "future
status" work? It might if we eliminated the target time for future status --
"I expect to be available for calls sometime".
Issue #3: Three Dimensions
Do we need to model these in the data model? Proposed "No". Consensus reported
on this proposal.
Issue #3 Device ID URN
Proposed to note that these things can change, that they can be derived from
different things, and punt the detail implementation for each of these to new
Issue that we need to be able to differentiate an correlate information from
separate devices vs. correlate information for one device with multiple IDs.
So, what's the problem with UUIDs? Since they are randomly generated, sometimes
from a MAC, can they be correlated with a MAC address? Are they "invertable?
Arguable that they are not -- one cannot assume that just because a UUID has a
MAC address in it that the UUID is from the device that has that MAC address.
Action Item: We need to check on relationship between UUID and ESN, MEID, IMEI,
and IMSI from mobile worlds.
Noted that this mechanism works, it just works better if we have more information.
Proposed: To note that the draft use a UUID URN as the baseline, and allow
others as available. Rough consensus observed.
Issue: Multiple device IDs.
Noted that we need to clean up the difference between the device-ID element and
the ID element of the device. Rough consensus reported on a single device ID
Presence Authorization Rules
Changes since last draft reviewed.
Issue #1: Blacklists and matching.
Proposal offered by author. Response controversial. Noted that real world cases
seem to require cross-domain listing now.
Much debate ensued. Author will add many caveats about identity minting.
Henning and others will discuss additive properties.
Issue #2: Glob Matching
Proposed and accepted; do not add this feature.
Issue #3: Filter-based sub-handling
Proposed: leave as is; Accepted.
Issue #4 Tel URI
Action item: Make sure it works with tel URI as an identity.
SIMPLE Session II - 8th March 2005
Recorded by Dean Willis
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
Proposed that document is ready for working group last call
Topic: MSRP Relay
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
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
Comment: It's possible that we might discover from XCON that extensions are
needed to lots 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
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
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
Comment: You probably want to look at xupdate, which is W3C work to do the same
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
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) represents 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
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
Consensus reported to proceed with adoption.
Topic: User Agent Capability Extension to PIDF
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
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.
SIMPLE Session II - 8th March 2005
Provided by Chris Boulton
MSRP Core - Ben Campbell
- Discuss SDP changes - Review + concerns by MMUSIC on usage
- Compromise solution based on copying address + port to conventional locations
- Now referencing SDP new.
- Added new response codes.
- Other general cleanup issues sorted out in version 10 (security, IANA,
-From list - Incremental REPORT vs Whole message. Do not add feature for
client to set preference at this time.
-From list - Overlapping chunks when failover - WG consensus - its the
receivers problem - clarify text.
- Robert Sparks : START WGLC AT THE MIC.
MSRP relay - Cullen
- Explanation of new AUTH processing (shared secret)
- Other major changes covered (SDP, response codes, URI consistent with base
- Remove Stateless relay text to avoid future issues
MSRP Conferences - Miguel Garcia
- Overview of exactly what is in the draft + requirements + proposed extensions.
- Ben Campbell - We need a general solution, not specific MSRP extension -
should be XCON work.
- Brian Rosen - take your requirements and input to XCON rather than creating
protocol specific solution in SIMPLE.
- Paul - Believes there is a disconnect on the meaning of nickname
- Brian Rosen - nickname - need to get together to agree nickname XCON,
SIPPING, SIMPLE, SIP.
- JR - be careful when specifying new identifiers.
- Robert Sparks - way forward - mostly XCON with nicknames discussion needed in
XML Path Operations - Jari Urpalainen
- Start with a short overview
- Changes since last version of the draft
- OPEN Issues and Bugs review - Included proposed solutions (see slide deck)
- JR - concerns about technology. Why is this draft being positioned as a
replacement for XCAP?
- Robert Sparks - thinks this draft is anything but simple (as positioned)
- Cullen - Bunch of WG need Diff format for XML + are working on it. We seem
to be in the middle ground that describes a general mechanism for single
- Robert Sparks - FEEDBACK FROM ROOM - Do we want to produce specific XCAP
solution OR go outside the WG for a general purpose solution.
- Rohan/JR - if we are going to use XCAP we should produce an XCAP specific
- Robert Sparks - WG specific - proposal is not exactly what we want. Probably
need to tack back for XCAP specific and then PIDF OR look at a general
- Hisham - HUM - No Conclusion - take to the list.
Policy Capabilities - Jonathan
- Problem Statement - How does a client know which of the auth policies it
- Overview - Quick overview
- Open Issues + should this be adopted as a WG item?
- Robert Sparks - Should we adopt this work?
- HUM - suggests WG adoption.
Prescaps Update - Aki
- Changes discussed form last version.
- Rohan - Priority makes composition difficult.
- Open Issues - no major just a couple of minor. Update schema according to
schema workshop design decisions.
Presence Processing Model
- Overview of changes in latest version
- Draft represents bottom half of previous data model
- Issues covered