Alternate Afternoon

2.10.6 Interim Meeting SIP for Instant Messaging and Presence Leveraging Extensions (simple)

IETF-60 SIP for Instant Messaging and Presence Leveraging Extensions (simple)

Interim Meeting Morning Report - Morning Session

SIMPLE Interim Meeting
Morning Session Minutes
Monday 24th May 2004

  • MSRP – Ben Campbell (draft-ietf-simple-message-sessions-06)
  • New in 06 (slides)
    • Changed to/from to-path and from-path.
      • Semantics different than traditional to/from confusion insued.
    • Framing: Use boundary instead of length field.
    • SDP: Transport and TLS indicated in URL rather than M-Line
    • Inviter always opens the connections.
    • Updated DSN section.
  • Relationship to relay draft
    • Core specification talks about route path handling.
      • Makes minimum necessary assumptions about relay behavior to allow relays.
      • Does not talk about how relays work or how endpoints work.
  • Path handling in SDP
    • Each client puts a URL into a path attribute.
    • Can put more than one URL in the path attribute.
    • The path given by peer indications the ";Peer to peer path";.
  • Path handling in MSRP requests
    • To-path holds a list of URLS.
      • Path to destination
      • First URL is first hop
      • Last entry is destination.
    • From-URL also takes a list.
      • Where it's been?
      • Initial request has one entry pointing to client.
      • When request arrives at destination, it will contain URLs for all hops.
  • Request Framing
    • Length field goes away.
    • Add boundary header.
      • Random string (different for each message)
      • Matching closing field
        • 7 hyphens
        • Boundary string
        • Continuation char ($ if content complete, + if more to come).
  • Request Framing (part 2)
    • There's a lot of confusion of MSRP boundaries being independent of the MIME boundaries.
      • Full MIME body between headers and closing. May have its own MIME boundaries.
      • Presence of MIME boundaries does not change use of MSRP boundary.
    • Boundary must not collide with payload.
      • Cannot use same boundary string for MSRP boundaries as MIME boundaries
    • (Cullen/Campbell:  Needed to take this approach so that we can interrupt a stream without killing the connection.)
    • (Henning: Worried that this is going to be so close to MIME that it could be confusing to implementers as to what's a MIME boundary, and what's an MSRP boundary. Might use MIME processing code to handle MSRP boundaries accidentally.)
    • (Rohan Mahy: We can change it if necessary.)
    • (Cullen: I agree w/ Henning, we can make it the same if there's confusion.)
  • Other SDP changes
    • Transport and TLS determined by URL scheme, rather than M-line.
      • Msrp: - TCP
      • Msrps – TLS over TCP
      • Smsrp – SCTP
      • Smsrps –TLS over STCP
    • SCTP related schema are ";reserved"; for whenever we specify the SCTP binding.
    • (Ted Hardy [AD] – Worried that you're reserving so many schemes.)
    • (Ben: Adam/Rohan/Cullen and myself had a discussion on this. Not beholden to this approach if there's something better out there.)
    • (Ted: May want to get some URI folk brought into the discussion. Not sure that you want to specify this in the scheme.)
    • (Ben: We have not gone through and said that you must support SCTP)
    • (Adam Roach: We wanted to show how different transports would appear in the URI)
    • (Rohan: There are a number of permutations that you can have.)
    • (Audience 1: Why not use SIP/SIPS approach?)
    • (Cullen: That's what I wanted.)
    • (Adam: MSRP does not lend itself to the same SIP/SIPS approach because of the way that MSRP works. It would be odd.)
    • -->Ben quickly crafts some examples in the slides:
      • msrp://host/asf:port:transport=tcp;protection=yes
      • msrps://host/adsf3:port;transport=tcp
      • msrps://host/tcp/asfed:port
    • (Ted: Not a lot of use cases out there that I can think of where every session that is used uses hop-by-hop TLS. Doesn't work that way for email. I'm not trying to say that this doesn't make sense, but I think it would make more sense to use a common URI scheme. I don't think that there is going to be a collision problem in the future if the various schemes were not registered all at once.)
    • (Jon Peterson: The only reason we did SIPS at all is to allow an immediate failure if there is no host listed in DNS that did not support TLS, that there would be an immediate failure.)
    • (Adam: How do I specify on that link that I want TLS or failure for MSRP?)
    • (Jon: Don't know.)
    • (Rohan Mahy: I think we've found a requirement that we should be able to specify whether a missing transport is a failure, or if any type of transport is OK. We had said that there was no negotiation possible, that you could look at the list and figure out immediately what you were going to use.)
    • (Ben Campbell: In MSRP there is no NAPTR lookup.)
    • (Jon: Perhaps we can defer this discussion later to when we've determined if we need SCTP, etc.)
    • (Adam: We need to know if it's going to be an opaque token, or the scheme now. We can't mix and match later. We don't need to register the tokens, but we need to know the syntax.)
    • (Jon: I'm saying two things. If you use TLS, it has to specified in the transport address, and two, whether or not we need TLS.)
    • (Ted Hardy: What would happen if we said you always have to use TLS.)
    • (Rohan Mahy: The relay-relay communication must use TLS. Peer-to-peer connections aren't required to use TLS because certificate management is too difficult.)
    • (Ted Hardy: TLS lets you get beyond that.)
    • (Jon Peterson: I think Ted's question is interesting.)
    • (Rohan Mahy: This is worse, because we waste time on the TCP setup to know if we need to use TLS.)
    • (Jon Peterson: What do you do for authentication when TCP only is used?)
    • (Cullen: We use a URI that is secret and hard to figure out. It's not great, but that's what's there.)
    • (Jon Peterson: I don't see that TLS makes this any worse. If all you're doing is waiting for the SYN packet and dropping the connection because you don't like the looks of it, TLS is no worse.)
    • (Rohan Mahy: If I have no certificate that is meaningful to provide you, and you open a TLS connection, I have to have a completely different code-path to handle this connection.)
    • (Cullen: The smallest implementation for TLS is 120K. Are there any wireless device vendors here that don't want to carry 120K around with them?)
    • (Keith Drage: 3GPP does not specify that you must have relays at all.)
    • (Ben Campbell: I think that we've come to the conclusion that we have more thinking to do.)
    • (Jon Peterson: I don't like that conclusion. I think we should resolve it now.)
    • (Hisham Khartabil: If we think this should be in the scheme, then this is what we have. If you think it should be a parameter, then we need to know what that is now.)
    • (Ben Campbell: I think we've said that we can drop smsrp and smsrps from the URI combinations. Also, killing off msrps://host/tcp/asfed, where the transport is in the URI path.)
    • (Rohan Mahy: It was pointed out that we don't have to select all of the schemes immediately, we should go to the URI list and let folks know what the options are.)
    • (Cullen: By not saying anything, we're choosing the scheme approach.)
    • (Jon Peterson: We're saying that extensions to MSRP are going to have to specify additional parameters anyhow, so inclusion of parameters means additional work ala TLS, etc.)
    • (Adam Roach: That doesn't work because a relay that's not familiar with the extension won't interpret the parameter correctly.)
    • (Rohan Mahy: I don't need to know what parameters are if I just stick them into the list.)
    • (Jon Peterson: Can we say that this is version 1 of MSRP, and that we version out the problem. You can put the version in the scheme.)
    • (Ben Campbell: That's pretty much what we're doing.)
    • (Jon Peterson: I want to close this out.)
    • (Rohan Mahy: [Question to Room] does anyone have a problem with always having to have transport=tcp in the URI.)
    • (Jon Peterson: Doesn't make sense to have a protocol with one transport have a parameter specifying the transport as a mandatory element.)
    • (Hisham Khartabil [WGC]: No transport parameter means TCP.)
    • (Ben: I wanted to specify TLS as a transport.)
    • (Ted Hardy: If you want to see this as an orthogonal parameter, then TCP remains the default, and you negotiate towards TLS. I still would like to have the URI folks take a look at this for a little bit to ensure that we haven't made a mistake.)
    • (Ben Campbell: For the sake of closure, would it make sense to have this room pick a candidate to send it to the URI folks.)
    • (Aki Niemi: Is the behavior that we intend to be failure if I don't understand what you're asking for, or do I fail-back to TCP?)
    • (Ben Campbell: There's a question as to whether or not we can fail-down to TCP.)
    • (Robert Sparks[WGC]: We can always approach this as an offer-answer model to negotiate down to TCP.)
    • (Ronnie: The behavior needs to be clearly specified.)
    • (Robert Sparks [WGC]: Need to move on.)
    • (Ben Campbell: I was going to say that we go with msrps://host/asdf3;transport=tcp. TLS goes into the scheme, there's a transport parameter.)
    • (Robert Sparks[WGC]: Need to specify the equality rules for what happens if a transport is missing.)
    • (Ben Campbell: If I put MSRP in the SDP I must put the transport in there.)
    • (Adam Roach: Can we simply make it ";;tcp";?)
    • (Ben Campbell: Sure.)
  • Connection Handling
    • Default to TCP connection opened by client that sends the INVITE.
      • No COMEDIA
    • Active client MUST send an immediate MSRP request, so the peer can tell who opened the connection.
      • May be SEND if there is a message to send right away.
      • Otherwise use VISIT.
    • Inviter must wait for answer before connecting.
  • Delivery Status Nofitication
    • Only specifies enough to let an endpoint without relay support talk to peers that use relays.
    • RFC1984 format
    • DSN requested on per request basis.
      • Receipt-Request header field.
        • Negative – only report on failures (relays only)
        • None – never report
        • All – report failures and delivery success.
        • (Might need a fourth one, positive, opposite of negative)
      • Default is ";negative";
      • Sent using REPORT method
      • Never REPORT on a RECEIPT
  • Message Fragmentation
    • May break content into ";parcels"; using message/byte ranges
    • Only message/byte ranges content can be interrupted and resumed.
    • SHOULD fragment anything over 2K.
    • Final parcel uses ";$"; in the continuation flag field. Non-final parcels use ";+";
    • (Adam: The should fragment is a little bit misleading. You should make fragmentable anything over 2K, so relays can chop it up if they want to, but it's not mandatory.)
    • (Robert Sparks[WGC]: If I'm in the middle of sending one of these huge streams, and I get a request I need to respond to, I can interrupt what I'm doing to respond rather than running into the head-of-line problem.)
    • (Rohan: If I'm an MSRP client that receives a SEND, that contains a boundary with a ";$"; I know I'm safe to render. I might buffer on a ";+"; and send a DSN though.)
    • (Cullen Jennings: If the total is ";*"; I don't understand what the ";$"; does for me because things may arrive out of order if we go through relays.)
    • (Adam: They can go through different paths through A-record round-robining. We need more text around the ";*"; mechanism, but it works.)
    • (Ben Campbell: DSNs indicate delivery, not rendering or viewing by the user.)
    • (Aki Niemi: What if I want to abort, how do I tell the sender to stop?)
    • (Ben Campbell: There's no way for the receiver to tell the sender to abort. I'm running out of memory. I want to stop things without interrupting my connection to the relay.)
    • (Cullen/Robert: Download should be a separate session. Can send a re-invite to get a new stream or a BYE.)
    • (Audience 1: We really don't say what muting a connection does for MSRP. We should perhaps expand what that means.)
    • (Aki Niemi: With relays involved, I see two ways to do the same thing. Can we pick one that works both end-to-end and with relays so that we only have to support one method.)
    • (Ben Campbell: Can we defer this? I'd hate to make end-to-end connections support REPORT because I don't want chaining properties.)
    • (Jon Peterson: Have we closed with the MIME folks to see if the usage of multi-part byteranges here meshes with their use?)
    • (Ted Hardy: This does turn it into a bucket MIME type because you don't know what the real MIME type is going to be. It's always set to multi-part.)
    • (Ben Campbell: Do we need to negotiate partial/multi-part MIME in the SDP? I hope not.)
    • (Ted Hardy: You might want to specify a parameter that lists what the internal MIME types are in the SDP so you can tell what you're going to get initially rather than later on.)
    • (Rohan Mahy: This message fragmentation is one of the things that I worry about the grey-beards of email pondering what we're doing.)
    • (Ted Hardy [AD]: I'll send one emails off asking about that.)
  • SDP Issues
    • How will SIP delayed offers work?
      • Can we expect the answerer to propose MSRP rather than voice?
      • Should we specify what a client that supports MSRP should do if it gets an INVITE with no offer?
      • Do we want this much SIP specificity in this document?
    • (Rohan Mahy: I was trying to prevent a race condition where in the SIP usage of this, if a SIP usage received an offer and wanted to answer, especially in the INVITE/200 INVITE/18x (reliable) that my client could not respond to this request because of MSRP work pending. If something occurs where I got an offer and I went to make a new connection, and setup a session of voice, and then update to setup IM, and TCP takes awhile… I may blow out the INVITE transaction timer and black hole myself. Once you receive the offer, you, as the answerer can do what you need to. Can setup the TCP connection and if it fails, re-INVITE.)
    • (Ben Campbell: Trying very hard to make MSRP not dependent on SIP. If I send an INVITE with no offer, why do I expect the other guy to ever send MSRP? [brief discussion] The problem of getting an INVITE without an offer is not an issue.)
    • (Rohan Mahy: The answerer needs to send immediately.)
    • (Ben Campbell: The offerer cannot send an MSRP request until the active party [answerer] send it a request, because if could be someone randomly connecting to the port.)
    • (Paul Kyzviat: We need to specify how re-INVITE works.)
    • (Audience 1: I agree. If the re-INVITE fails, what happens to the original connection?)
    • (Aki Niemi: The text is confusing on this area.)
    • (Ben Campbell: I believe there's some errors in the text. I need to revise.)
    • (Rohan Mahy: This was heavily cut & pasted from SIMS which was heavily cut & pasted from a memo between Cullen and I.)
    • (Adam: Why not simply use offer/answer rules.)
    • (Rohan Mahy: If that's the consensus of the group, I'm OK with making sure there's no holes in that.)
  • SDP Issues
    • Old text on updated offers obsolete with new approach to connection direction.
    • Section needs a re-write.
    • SDP offer/answer arcane experts please help (contact Ben).
  • Connection Direction
    • Number of non-relay scenarios reduced
      • Offerer must choose whether to use relay prior to making offer. If the answer is not firewalled, the offerer cannot learn of this until too late.
      • Thus, a firewalled answerer will always propose a relay, even if the answerer is reachable.
    • A firewalled answerer must use a relay, even if the offerer is reachable.
    • (Cullen: If the device that is behind a NAT that breaks the network, they must use a relay.)
    • (Aki Niemi: Any device behind a firewall always has a path that it must put in its SDP, the offerer has one, and the answerer has another, how does that work?)
    • (Ben Campbell: That never happens in the core spec. It needs to go in the relay spec.)
    • (Aki Niemi: Issue is not clear.)
    • (Ben Campbell: Text needs to be updated to make this clearer.)
  • Fragmentation
    • How much of the RFC-2616 language concerning message/byte ranges do we need to reproduce here?
    • Currently only refers to RFC, and add tect that specifically constrains the use in MSRP. Does not explain message/byte ranges in general.
    • (Henning: Is that text sufficiently contained so that someone doesn't have to read all of 2616?)
    • (Ben Campbell: yes.)
    • (Adam: We've made some modifications, like wildcarding that needs to be explained.)
  • SEND vs. VISIT
    • VISIT has become less important
      • VISIT only serves to identify the active party to the passive party, in the context of a particular session.
      • Active party may jump straight to SEND if it has context to send.
      • Since the active party initiated communication in the first place, it probably has content.
    • Can we remove VISIT entirely?
    • Should we require VISIT all the time, and not overload SIP?
    • (Rohan Mahy: If you were in fact, able to come up with the URI, then you can send the VISIT. You need TLS to authenticate.)
    • (Adam Roach: If you are starting up a session that has multi-media associated with it, we may not setup Ims immediately. The second scenario is conference…)
    • (Ben Campbell: I never said it always has to SEND. We could send an empty SEND, or we could simply not overload the method. Offerer would have to VISIT and then SEND.)
    • (Rohan Mahy: If you have something to send, SEND, otherwise VISIT, which is what the text says.)
    • (Ben Campbell: Propose leaving VISIT in the draft. If SEND with no body will work, I'll rip it out, but it'll have to be decided soon.)
  • DSN Issues
    • Do we need them at all?
    • What about DSN reports after session is over?
    • Should we default to no DSN for peer-to-peer session?
      • DSN is redundant with transaction responses for p2p?
    • DSN section needs to be updated to use new handling of to-path/from-path.
    • (Ben Campbell: Intent was that if next hop failed, the reason code was included.)
    • (Rohan Mahy: Want to base this on message ID and not transaction ID.)
    • (Ben Campbell: Old draft. Has been/will be fixed to message ID.)
    • Ben Campbell: If we have a response that says ";stop sending me crap without TLS"; do we need TLS negotiation?
    • Adam: Sounds like it's mandatory for TLS to be used between relays.
    • Rohan Mahy: I'd be perfectly happy with if the URI contains a port/transport/protection level explicitly, the server knows if the port offered supports what was asked for.
    • Cullen Jennings: I'd rather avoid the peek 3 bytes ahead issue around TLS.
    • Ben Campbell: I was going to send an explicit start TLS. But if I know that I'm always going to do TLS why do I need a response code that says do TLS? Does anyone have any heartache over removing negotiation between relays around TLS? [Room is generally quiet, Henning agrees


  • Rohan's MSRP Relay Draft Discussion
  • Ben Campbell: We do request/response, request/respone, etc. as opposed to request, request, request… response, response, response.
  • Rohan Mahy: Yes. If a message goes from a fat pipe to a slow pipe, I know how long to wait for a response at the sender from a SEND. It also allows chunking at the relays.
  • Orit Levin: I think MSRP is not going to be useful without the relay draft. This piece is very important. We should dicuss this draft from a conceptual point of view. For instance, does it make sense for the user to know about all the relays in the path. It may not be practical. I fear that we may be wasting time by discussing each method, when we have not gone over the basics.
  • Rohan Mahy: I hear that you have an issue with relay discovery beyond the first relay. I would like to discuss that. I'd like to discuss the flow though as it has more profound impacts on the protocol.
  • Robert Sparks[WGC]: We're going over the various methods to see if we have something missing in the architecture or something we don't need.
  • Rohan Mahy: We can discuss this.
  • Hisham Khartabil[WGC]: Chunking will only work if request/responses are end to end.
  • [Moving on to relay discovery]
  • Rohan Mahy: I can use DNS-SRV to discover a relay. Requires more work by the client.
  • Orit Levin: From my perspective, I don't want my client to know about subsequent relays and that it may not be able to authenticate with those relays.
  • Rohan Mahy: It can be hidden.
  • Orit Levin: When relays know about each other, and authenticate with each other explicitly, I don't think it's important that the client talk to the relays directly.
  • Rohan Mahy: Draft needs work. Will be updated. 
[END OF Rohan's MSRP Relay Discussion]
Orit Levin's MSRP End-to-End Discussion:

  • Two Distinct Mechanisms
    • Application Later: End-to-end
      • For application use
    • Network Layer: hop-by-hop
      • For improved feedback (to application layer) in case of network failure.
      • Require configuration of the first relay (only)
    • The very first deployment will use RELAYs
      • Don't build interim solutions for one hop only.
    • End-to-end abstraction MUST be provided even over a single hop.
      • Applications need to be exposed to the end-to-end view ONLY.
    • (Orit Levin: Endpoints can't know the network topology. First implementation of MSRP will include relays, I don't see the overall model in our discussion.)
    • (Ben Campbell: The main reason we're breaking up relays from the core draft. It's an IETF process decision so both drafts can move forward.)
  • Hop-by-hop Mechanism
    • Added Value
      • Automatic negative feedback in case of TCP link failure without additional application logic: requires state information (at least MSRP connection) in relays.
      • Ability to specify (with high probability) messages that have been affected by the failure – requires per message state + 200 OK.
      • Improving timing for ";stalled"; TCP connections – requires ";per something"; state + ";200 OK"; + timer.
    • Issues
      • Specific message information can be misleading.
      • OVERHEAD for BIG deployments (>25%, easily 50%)
      • Lack of throttling manageability for MUXing and CONFERENCING.
    • (Cullen: The error case you propose in your draft, I'm not sure that if the network disappears at the right point in time you can't get a response back. It's unsolvable.)
    • (Ben Campbell: Looking at the models you describe in the simulations you ran a modified SIP state machine to get your numbers. SIP is a far more complex state machine than MSRP. Because of that, because of the timers and things that MSRP doesn't have to do, the overhead is proportionately less. I think you'll come up with a significantly lower number. However, it still becomes an efficiency vs. generality argument.)
    • (Orit Levin: I think the number will go up, rather than down. For MSRP the amount of work being done goes way down and the overhead becomes larger.)
    • (Ben Campbell: Based on that, a test based on SIP doesn't tell us anything. It could be higher or it could be lower.)
    • (Cullen Jennings: Perhaps if DSN is set to NONE, we don't set any timers, and don't send back any responses.)
    • (Orit Levin: I would like for us to deal with what we would like to achieve, and then work into the messaging, rather than the other way around.)
    • (Robert Sparks[WGC]: If we don't send responses, the DSN only tells us something failed, and not when. Every session that happened to be on that TCP session [ever] is going to get a DSN back that something failed.)
    • (Adam Roach: One of the requirements of a relay is to be able to operate statelessly at the session level.)
    • (Cullen Jennings: I want a reliable model, and you want an unreliable model.)
    • (Jon Peterson[AD]: I understand that what you want to do is revert this entire discussion to requirements. We've done that before here at SIMPLE.)
    • (Orit Levin: I want to show what the implications are. They need to know what will happen.)
    • (Jon Peterson: You want to start over with a new protocol, with different assumptions.)
    • (Orit Levin: We can go through with Cullen's suggestion, and we can go through the rest of the slides.)
    • (Jon Peterson[AD]: We're required by the CPIM RFCs to be reliable and provide positive acknowledgements.)
    • (Jonathan Rosenberg: If we can reach a compromise, let's do so.)
    • (Adam Roach: We're building TCP over TCP.)
    • (Robert Sparks[WGC] – Tried to gain consensus, but still muddied.)


Robert Sparks
Hisham Khartabil

Rohan Mahy
Adam Roach
Ben Campbell
Henning Schulzrinne
Keith Drage
Jon Peterson
Kurt Bertone
Peter Mataga
Jonathan Rosenberg
Paul Kyzivat
Gonzalo Camarillo
Christer Holmberg
George Foti
Thomas Froment
Shida Schubert
Cyrus Shaoul
Dorothy Gellert
Markus Isomaki
Aki Niemi
Anwar Siddique
Ashir Ahmed
Mahfuzur Rahman
Bob Penfield
Yaron Reinharts
Cullen Jennings
Ted Hardie
John Elwell
Orit Levin
John Lawser
Martin Dolly
Alan Johnston
Henry Sinnreich
Miguel Garcia
Mihko Lonnfors
Radhika Roy
Bill Marshall
Chris Boulton
Christian Schmidt
Kumiko Ono
Dan Petrie
Roni Even
Francois Audet
Mary Barnes
Brain Stucker
Dale Moberg
Scott Bradner
Kwok Ho Chan
Asher Shiratzky
Dean Willis
David Oran
Tom Phelan
Mark Zeren
John Buford

Interim Meeting Morning Report - Afternoon Session

SIMPLE Interim Meeting
Afternoon Session Minutes
Monday 24th May 2004


XCAP Open Issues
Jonathan Rosenberg
Slides presented

Issue 1: Schema Extensibility

Proposed on-list that schema be appleid only to validation, and that
insertion location be determined by client. No disagreement noted on
list or in meeting.

Issue2 : Positional Insertion

Operator and predicate suggestions made on-list.

Discussion in the meeting explored the complexity level of XCAP with
the suggested mechanism versus possible simpler approaches. No
conclusion on this point.

Also proposed that we consider the "simplifying assumptions" that are
applied, for example flat structures.

Three options proposed:

      1) Flat structures -- contain the schemas to prevent failures.  

      2) Servers that support specific address/location model or
      top-level replacement only.

      3) Servers that support full xpath-like specificity.

It was suggested that the servers should be able to negotiate the
granularity of their policy.

Comment: If this xcap stuff can't be done as a reasonable student
project, it isn't happening.

Decision making process. Rohan proposes that anyone suggesting "moving
the bar" here should provide detailed examples that illustrate what
they are doing and why the existing approach is inefficient.

Discussion: How many customers for XCAP do we see? Does this justify a
full-on, all possible capabilities design, or something optimized for
the specific customers?

No decision reached in meeting and analysis will continue.

Issue 3: PUT v POST

Modifications proposed on list to preserve idempotence and get(put(x))=x.

Debate point: Is there any point to having clients submit request with
"blank" required parameters? Wouldn't it be more efficient to have the
client make something up, which the server could reject if needed?

Poll for consensus on PUT v POST: None opposed to PUT.

Issue 4: Element Separator

Conclusion - two tildes, as in "~~"

Issue 5: Multiple Insertions

Issue is in preserving idempotence on multiple insertion operations.

Two algorithms presented for consideration.

Mentioned that there are numerous efforts to define XML database
operations. We shouldn't try and reinvent them here.

Discussed that most operations that seem to require transactional
multiple-element operations can be avoided by careful design of the
schema. This leaves the question of where to document this
approach. The author proposes that the XCAP document provided a basis
of discussion here.

Noted that schema design can allow overlapping (pipelined) PUT

Proposed: We do not pursue multiple insertions at this time, but add
discussion on schema design issues into the specification. Rough
consensus for this appraoch was recorded in the meeting.

Issue 6: Selecting Elements by Text Content

Currently selectable by position and attribute value, but not text

Several proposals for content matching have been considered.

Proposed: We wish to exclude selection by text content from the
specification at this time. Rough consensus for this approach was
recorded in the meeting.

Issue 7: Unique Hops in Schema

Proposed that we mandate unique element "key" tags for elements with
max-occurs > 1.

Poll: Do people agree that each level of an XCAP reference must be
unique? Consensus recorded. Note: We need to check to see that we can
enforce this constraint without checking each instance document.

Issue 8: Finding out scope of change.

Four solutions proposed for consideration.

No conclusion on approach recorded at this meeting. Noted that we have
to stay as semantically close as possible to the basic etag

Presence Authorization Rules
Jonathan Rosenberg
Slides Presented

Slides reviewed current authorization document format.

Open Issue #1 Default provide-contact

Proposed: Provide Unknown Status. No conclusion noted.

What is a Tuple?
Jonathan Rosenberg
Slides Presented

Proposes several ideas, all of which appear to be controversial.


Event Filtering
Hisham Khartabil
Slides Presented

Issue 1: Allowing multiple filters per target. Consenus to disallow.

Issue 2: List-expansion of elements in a filter yields elements that
do not exist in the list. What do we do with these elements of the
filter? ZCurrently, these are passed on to any list subscription, in
case the filter actually appleis to a list within the list. Proposed
that this pass-through effect be limited to filters that are targeted
to domains outside of the scope of the RLS. This raises questions
about handling of lists that recurse back to the domain of origin. No
consensus recorded in this meeting.

Issue 3: Should lters of higher specificity override filters of lower
specificity? Proposed "yes". No objections reported. Cullen has a
funny feeling he may be able to come up with examples where this
doesn't work, but doesn't have anything now.

Issue 4: How to remove a filter. Consensus on Proposal 2, remove or
replace using the same filter ID.

Partial Publication
Aki Niemi
Slides Presented

Background presented.

Poll: Is there a need for this? No clear consensus either way recorded.

Interim Meeting Morning Report - Alternate Afternoon Session

XCAP Open Issues

May 2004 Interim
Jonathan Rosenberg

Issue 1: Schema Extensibility

  • Problem
    • Schema awareness used for two purposes
      • Document validation
      • Determining where to insert
    • Requiring schema awareness limits extensibility
      • PIDF extensions for example
  • Proposal
    • Schema awareness only used for validation
    • Where to insert must be specified by client
  • Benefits
    • Eliminates some of the PUT "magic"
    • Allows extensibility (resulting data just won't bevalidated)
    • Can still validate parts that are known
  • No disagreements on the list
No additional comments in meeting. Agreed.

Issue 2: Positional Insertions

  • Currently, no way to insert an element in a specific place
    • Goes on end if its an insert
  • Problems
    • A big one if schema awareness not used to determine where to insert
    • A limitation for schemas where position is significant (i.e., CPL)
  • Proposal
    • Allow the "*" operator to select all children of anode
    • Allow multiple predicates (i.e., multiple [])
    • Allow name() function as a predicate to pick an element by name
  • These allow positional insertions
  • Was agreed on list
Henning: Minimum implementation threshold too high. Need customer input for some of the more high level functionality. Is this one of those things? Could be done by replace all, or delete and insert.

Ted: Where is the line? XCAP rather than XPATH. One of simplifying functions was to treat XML docs as if they were a store of resources. Can be referenced by their place in a hierarchy. Instead of handling positional insertions, know where appropriate place is to do a full fetch and return. Easier in one view to do it this way, but requires more download and upload.

Henning: Propose levels of optional capability. i) Simple flat listing .ii) 1st level insertions only. iii) Every client and server has to support all functionality.

Jonathan: Not in favour of options.

Jonathan: Look at primary customers: Presence auth, XCAP, CPCP do they need it?

Cullen: Should not stray into multiple positional insertions, should stick to single insertions.

Rohan: Should not agree new capabilities without concrete examples of usefulness.

Hisham: Not efficient from air interface.

Henning: Documents not necessarily large anyway.

Hisham: Ordering of elements may matter.

Jonathan: This wont work for that, but if this matters, then document should be designed to avoid this. Need an order of priority field. XCAP will work with all schema, but works better with some schema than others.

Henning: Number of reasons why SQL is more trivial than this.

Ted; How many customers do we need to prove it works. Doing it in SIMPLE was to constrain it to a small set of applications. We are trying to optimize for a specific application domain. Thus manipulation of schema is acceptable if it makes things simpler.

No agreement on whether we need this or not. Do an analysis on existing schema and see what impacts are.

Issue 3: PUT v. POST

  • Is what we're doing a PUT or a POST?
  • Currently is unclear because
    • The server can modify data
    • Modeled as a virtual application ugly
  • PUT litmus test
    • GET(PUT(x))=x
    • Idempotence
  • POST is a slippery slope, will invite scrutiny
Adam: Why cannot use random 64 bit identifier. Near enough unique.

Adam: Why would a client ever do the first two steps (PUT w/o needed data; 409, body suggests data, without data change).

Jonathan: We have a requirement. If you don't like it, maybe we should change the requirement.

Cullen: Thinks this is a non-requirement, and leads to things we don't want.

Dean: Would it be nice to have the namespace as dense as possible?

Agreed: Client will always provide data, and the server will then reject it if necessary. Therefore no case when the client does not provide data.

Proposed Server Data Method
Drawing the Line

  • User PUTs data, server doesn't modify, no validation at all
  • User PUTs data, server doesn't modify, but it will reject the request if its invalid for any reason schema, URI uniqueness, etc.
  • User PUTs data, server modifies data before storing
Conclusion: Put is good and we should stick with it. This repeats concensus that we already have from last meeting. Post not to be used.

Issue 4: Element Separator

  • The issue that won't die
  • History:
    • ?
      • Problems with proxies
      • Not a good model
    • #
      • Executed locally, we need server based
      • Nothing
      • Hard to implement
    • ~
      • Might exist in host path component (there is precedent)
  • Desired characteristics
    • Disallowed in XML names
    • Allowed in HTTP URI abs_path
    • Usually not used in host paths
  • Does existence in host paths matter?


A transparent proxy MUST NOT rewrite the "abs_path" part of the received Request-URI when forwarding it to the next inbound server, except as noted above to replace a null abs_path with "/". Note: The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been known to rewrite the Request-URI.


  • RFC2396 "mark" characters are {- _ . !~* ‘ () }
  • Of these XML disallows {! ~ * ‘ ( )_(alone) .(alone)
  • Proposal: single quote "'"
  • Mandate that this can't appear anywhere in document selector
    • XCAP is all about constraining URI structure
Ted: Does it have to be a single character. Proposes ~~

Jonathan: No.

Henning: Quotation marks delimit in HREF.

Other comments that quotes get changed by word into other things.

Conclusion: Agreed that ~~ will be used as the delimiter.

Issue 5: Multiple Insertions

  • Problem(?)
    • XCAP currently allows manipulation of a single element or attribute at a time
    • Requires multiple operations to add several buddies
    • Some have complained about this limitation
  • Proposal on list to allow for manipulation (get, insert, modify) of multiple elements

URI Structure

  • URI represents a resource that is ";view"; of a portion of the document
  • GET on the URI returns that view
  • PUT on the URI sets the view to the value in the body
  • Key Constraint
    • Series of URI components represent the URI after document modification is done
    • Needed for idempotence

Idempotence Defined

  • idempotence is the quality of something that has the same effect if used multiple times as it does if used only once
  • HTTP PUT and GET are idempotent


  • How to find out where to insert each element so that the URIs match those elements in the final document?
    • Don't want to search!
  • Idea: implement as a series of individual operations
  • Question: when does a series of individual PUT operations give you the property that it is equivalent to a PUT of the view?
    • i.e., when is this idempotent?

Proving Idempotence

  • Basic proof
    • Assume PUT of an individual element is idempotent
    • A sequence is idempotent if, after the sequence
      • Each URI points to the same element
      • Value of the element is the same
    • Doing the sequence at once is the same as one at a time if there are no errors in between

Proving Idempotence

  • URI points to the same element if
    • No other modification touches its grandparents or higher antecedents
    • Parent has changed only by having new children
    • New children don't interfere with the way the element is addressed
      • Don't get inserted before it, if it is addressed positionally
      • Don't have same attributes as used to address it
  • Content of the URI is the same if
    • No other modification touches that element
    • No other modification touches its children

Example Problem Case

Server side algorithm I Try and Fail

  • Put each element, one at a time
  • Execute an internal GET on each URI in the request
    • Each has to return one thing
  • Series of elements has to be the same as body of PUT

Server Side Algorithm II -Verify

  • Need to verify the properties discussed previously
  • These are hard to verify
    • For example, checking ancestry seems O(N2) where N is number of elements inserted
    • Checking 1c grows with complexity of ways of addressing element

Do we want this?

Jonathan: Do not want to do multiple insertions in the initial version of the document.

Henning: XML database work is already in progress elsewhere. Should not do amateur database design here.

Hisham: Gave example of dial out list and dial in list to identify issue where we need this.

Cullen: Can be done as two PUTs.

Jonathan: Use multiple PUTs, Etags, careful schema design, etc, rather than do this.

Aki: Should not do this.

Aki/Jonathan: 2 options:

  • Same data that appears twice and need to put both in. Fix is schema needs to index on these things.
  • If flat buddy list where need to add 20 buddies at one, do sequence of20 PUTs without Etags, and if careful in schema design, then pipeline approach gives efficiency.
Keith: Are we recording any guidance where we identify careful schema design as the solution?

Jonathan: Have proposed this but some do not like it.

Conclusion: Do not do multiple insertions. Will put guidance on careful schema design in the document.

Issue 5a: Multiple Attributes

  • So far, its been about multiple elements
  • What about inserting multiple attributes?
  • If we want it, XML-based attribute list body may make sense
    • Allows you to return more than one
    • However XML is not needed for that
  • Recommendation: no
Based on previous conclusion (issue 5), we will not go there.

Issue 6: Selecting Elements by Text Content

  • Problem (?)
    • Currently, elements can be selected by
      • Position
      • Attribute value
    • No way to select an element by text content
    • Requires schema to put all relevant indexing data into attributes, even when content would be better

Issue 6 Proposal

  • Add the "X"] predicate
  • Can then ask for an element by content

All is not rosy!

  • What if element content is very large(e.g., paragraph of text)
    • Will be hard to index
    • May not want to store locally (Joel)
  • Same could be true for attributes, though!
  • Meta-Issue
    • Only want to select on things which are known to be indices
    • The things that are indices are application usage specific
    • XCAP selection rules are not application usage specific


  1. Allow application usages to define indices for their data
    • Complicates general purpose xcap code
    • Improves performance
    • Allows efficient purpose specific implementations
  2. Allow attribute or content indices, leave it to clients to only use useful things as indices
  3. Allow attribute indices, still leaving it to clients to only use useful things as indices, less likely to be problems
Option 3 is don't allow for content based selection.

Cullen: Does this only apply for text content? Mixed elements are out. Lot of hassle in doing this and absolutely no requirement for doing it.

Jonathan: Constrain schema into not doing this.

Rohan: Unless someone can come up with a use case should not do this.

Brian: Also thinks should not go this way. Taking it outside scope of the protocol. Trying to match things within an XML tag. Could accomplish it by grabbing the entire ACL list.

Conclusion: Will not select elements by text content.

Issue 7: Unique Hops

is it legal to have an XCAP reference of the form

Issue 7 Considerations

  • Can eliminate this by mandating unique results in each step
  • Server thus needs to check this
    • Hard if you're using off-the-shelf Xpath
    • Desirable if you are implementing from scratch
  • Performance better if each step has unique result
  • Proposal: mandate uniqueness at each step
Proposal is not to allow XCAP references with multiple levels with non-uniqueness, but to mandate uniqueness at each step. If use XPATH implementation, then this is allowed. Jonathan thinks it is not a good route to use XPATH to develop XCAP.

Hisham: If any element has max occurs of 1, then do not need. If more than one, then have to use id.

Jonathan: This does require scheme awareness.

Conclusion: Agreed will not allow XCAP references with multiple levels with non-uniqueness, but to mandate uniqueness at each step.

Future action is to check to see if can enforce this constraint without requiring a check of the instance document.

Reminder: Etags

  • Current specification doesn't reflect consensus from IETF 59
  • Consensus was
    • Application usages define scope of an etag
      • One choice is applies to whole document
      • Other choices each buddy list in a document has its own
    • This is not mandatory behavior
      • If client guesses wrong, may need to refetch broader scope
  • Details
    • "Scope" is defined by parent
      • All children of that parent have a different scope
      • Parent has to exist in each document, or if not, scopes need to be declared for each parent that could exist
    • A change in an element implies gives it etag X, and
      • All other elements and attributes in the same "scope" get that etag
      • All elements in higher scopes get that etag
      • Siblings do not get that etag

Issue 8: Finding out scope of change

  • Problem
    • Document has two buddy lists, X and Y
      • X has etag=1, Y has etag=1, doc has etag=1
    • Two xcap clients, A and B have full doc and etag
    • A does conditional PUT to X conditioned on etag=1
    • Succeeds, updates X. New etag for X is 2, Y is 1,doc is 2
    • B does a conditional PUT to X conditioned on etag=1
    • Fails
  • Question: how does B know whether
    • Only X changed
      • So only X needs GET to sync up
    • Entire document changed
      • Entire document needs to be GET to sync up

Issue 8 Solutions

  • Solution A
    • Use SIP event package, it will tell you what changed and the new etag
  • Solution B
    • Client assumes only innermost scope
    • If it was wrong, later PUTs in a broader scope will fail, in that case, get the next most encompassing scope
      • Orthogonal to Solution A
  • Solution C
    • Some kind of indication in the body of the 412
    • Not clear its allowed
  • Solution D
    • Go back to document wide etags
Not yet placed on the list.

Rohan: If not yet found out what document wide Etag is, then use solution B.

Ted: Presumption is that each individual resource has an individual Etag. When X updated, no presumption that there is a change in Etag for Y. Only the fact that we have an enclosing resource conception causes some knowledge of some other change. If think that it has changed, then conditional GET on Y is available. Sticking to a solution that is as close as possible to original Etag design is preferred. If so, solution A is out of contention; we need something in XCAP itself. Solution B is correct compared to solution D; talking about resources as opposed to documents.

Aki: How do we keep the data synchronized? Make a get for each individual buddy list separately. If Etag has changed, then get error code.

Conclusion: Put to list.

Issue 9: Knowing Supported Namespaces

  • Previously, it was important to know supported namespaces on server
    • Client had to be sure server knew them for XCAP to work
  • Now, its not so important
    • If server doesn't know, no validation
  • Do we want a way for the client to discover this?
    • Maybe defer for later
Not covered.

Known To-Dos

  • Change MIME types to xcap specific ones, rather than application/xml-fragment-body and application/xml-attribute-value
  • Terminology rework: xcap resources, not xcap servers
  • More examples(?)
  • Match AUID grammar with URI grammar
  • Clarify default namespace behavior
  • Document URI escaping and update examples
  • Clarify redirection behavior
  • Clarify filename extension behavior
  • Document if-none-match * to avoid creating new document but otherwise allow modification
  • Look at WebDav 409 body format –useful to us (doesn't seem so, but more work needed)
  • Insertions go in at the end if position is not specified
  • Update etag behavior etag scope is defined by application usage

Presence Authorization Rules
Authorization Document Format
Current Set

  • Conditions
    • <identity> - AOR of watcher
    • <anonymous> - watcher is anonymous
    • <sphere> - from common policy
  • Actions
    • <sub-handling>
      • Block deny
      • Confirm w/info
      • Polite-Block lie
      • Allow - OK
  • New transformation type: inclusion-set
    • Set of rules that identify to which tuple a permission is applied


  • <provide-contact-uri>
    • Inclusion set
  • <provide-activity>
    • Inclusion set
  • <provide-tuples>
    • Inclusion set
  • <provide-class>
    • Inclusion set
  • <provide-contact-type>
    • Inclusion set
  • <provide-relationship>
    • Inclusion set
  • <provide-sphere>
    • Inclusion set
  • <idle-detail>
    • No-time: leave off time
    • Full: include time
  • <provide-idle>
    • Inclusion set
  • <provide-placetype>
    • Inclusion set
  • <provide-privacy>
    • Inclusion set
  • <provide-unknown-status>
    • Next slide

Provide Unknown Status

  • Only applies to content for which there is no schemas for explicit permissions known to the server
    • Avoids overlap with semantic approaches that can be defined later
Spec calls out an open issue not on the slides. Two ways in which rule can appear. Need to couple this with a discovery mechanism.

Henning: Another solution would be to never extend the rule set. Anything in the future has to be done as listed on this slide. Another alternative is to avoid discovering the namespaces.

Henning: Not made a distinction between multiple facets of a condition.

What is a Tuple
RPID talks about four types

  • Device
    • Phone, PDA, PC
  • Service
    • Telephony, IM, SMS, email
  • Presentity
    • The user themselves
  • In-Person
    • The user as a communications medium
  • However
    • These are still not defined
    • Its hard to decide whether RPID attributes apply to one and/or the other
    • Device problems
      • What is the meaning of the contact URI
    • In-Person
      • How different from presentity?

Proposed Model
Mapping the Model to PIDF

  • Presentity status appears in a tuple with no contact
  • Each service is modeled with a tuple
  • A tuple can have a <device> element which indicates one or more devices and their characteristics on which that service resides
    • Device is thus another tuple attribute like the others

Henning: Determination is made by fallible devices, therefore no guarantee that presented status is correct.

Rohan: Do we mean device or instance?

Adam: If running two different client types, have one device.

Benefit of this Model

  • Easy transformation to "deviceview"
    • A pivot operation which unions together services that have the same device
    • Device isn't special as a presence attribute for pivot!
    • Resulting document is still a list of tuples, each representing a service
  • Easy transformation to"presentity view"
    • A pivot that just unions everything together
    • Result is a document with one tuple with a contact representing one service, "communications"
  • Eliminates need for "contact-type"
    • Tuple with no contact element is "presentity" and"in-person"
    • Tuples with contacts are "services"
  • Allows us to differentiate what status information belongs in which places
    • Child of <device>
    • In tuples with no contact
    • In tuples with contact

Benefits of Model

  • Nice tool for correlating services that exist on the same device
    • Device ID would be a meaningful URN
      • For phones, the tel URI
    • Allows correlation of device information received from non-presence sources (i.e., GPRS connectivity state) to affected services
    • Allows differentiation of published data received from different devices (my PC publishing "available for IM" vs. my cell phone publishing that)

Proposed Path Forward

  • Remove contact-type from RPID
  • Remove attributes that are devicespecific
  • Clarify presentity/service difference through contact URI presence/absence
  • Proceed with result
  • Produce a separate document introducing device concept and device attributes
  • Proceed with Robert's examples document that elaborates on this
Discussion as to whether device is a physical device or two instances of some abstract thing running on a physical device.

Conclusion: Tuple with contact id represents a service rather than a device. Tuple without contact represents presentity or in-person. Discussion of device identifiers would be dealt with in later documentation with its own set of open issues.

Event Filtering

Hisham Khartabil
Interim Meeting, Boston
24th May, 2004

Functional Description Issue (1)

  • A SUBSCRIBE request is allowed to carry multiple filters. Need to add text that disallows more than 1 filter per resource to be specified (eg: If the subscribe is for a list)

<?xml version="1.0" encoding="UTF-8"?>
    <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
        <filter id="8439" uri="">
        <filter id="999" uri="">
Conclusion: Do not allow more than one filter per resource.

Functional Description Issue (2)

  • Current text: "If the URI indicated by the filter is for one resource who's URI is NOT one of the URIs that result from a lookup, by the RLS, on the Request-URI, the filter is propagated to all the fanned out subscriptions."
  • List1 ( on RLS1 has:
  • List2 on RLS2 has:

Functional Description Issue (2)

  • RLS1 receives the following SUBSCRIBE request

<?xml version="1.0" encoding="UTF-8"?>
        <filter id="999" uri="">
        <filter id="8439" uri="">

Functional Description Issue (2)

  • Currently, this is propagated to RLS2

<?xml version="1.0" encoding="UTF-8"?>
    <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
<filter id="999" uri="">
            <filter id="8439" uri="">

Functional Description Issue (2)

  • Suggestion: if a filter is destined to a resource that is part of list that is outside the administrative domain of an RLS, then that filter is propagated. The rest are consumed.

<?xml version="1.0" encoding="UTF-8"?>
        <filter id="8439" uri="">

Adam: Preventing loops of resource lists. Need to make sure have not stripped out information that is used for determining this looping.

Functional Description Issue (2)

  • What if the list last was:
    • List1 ( on RLS1 has:
    • List2 on RLS2 has:
  • Proposal 1: Only propagate filters that are for resources not under an RLS's administrative domain. The rest are consumed
  • Proposal 2: Propagate all filters for resources that the RLS did not find an entry for in a list, including resources under its own administrative domain
Jonathan: Lots of looping issues follow same argument as in SIP. Deal with list looping with a subscription count header.

Adam: Doing spirals rather than loops in resource lists doesn't make sense. RLS are B2BUA, which are inherently not specified, and can go off into some other protocol which are not required to carry this info.

Hisham: This is out of scope of this issue, should have been dealt within event-lists.

Rohan: Propose that do not propagate any of the filters. Filter is consumed by 1st RLS.

Cullen: If I subscribe to set of filters, I expect it to make sure that these are executed. Contract between user and first RLS.

Jonathan: Therefore one option is to propagate as it so chooses, but this is not specified.

Adam: Therefore Adam needs text for the event-list draft covering this.

Conclusion: None. Take to list.

Functional Description Issue (3)

  • Need to clarify that a filter for an individual resource overrides a domain filter.
<?xml version="1.0" encoding="UTF-8"?>
        <filter id="8439" uri="">
        <filter id="999" uri="">
Conclusion: A filter for an individual resource overrides a domain filter.

Filter Format Issues (1)

<?xml version="1.0" encoding="UTF-8"?>
<filter id="8439" uri="">
  • When removing a filter, a subscriber must explicitly do so by specifying the filter ID along with the"remove" attribute set to True.
<?xml version="1.0" encoding="UTF-8"?>
        <filter id="8439" remove="True"/>

Filter Format Issues (1)

  • Problem: How does a subscriber replace a filter?
<?xml version="1.0" encoding="UTF-8"?>
    <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
        <filter id="8439" uri="" remove="True"/>
        <filter id="8440" uri="">

Filter Format Issues (1)

  • Proposal 1: disallow inclusion of‘uri' attribute when removing a filter
<?xml version="1.0" encoding="UTF-8"?>
        <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
                <filter id="8439" remove="True"/>
                <filter id="8440" uri="">
  • Proposal 2: Allow a filter to be replaced using the same filter id
<?xml version="1.0" encoding="UTF-8"?>
        <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
<filter id="8439" uri="">

Henning: Proposal 2 seems cleaner.
Hisham: Also his proposal.
Conclusion: A filter is replaced using the same filter id.

Side discussion of VISIT versus SEND while waiting. No conclusion.

Partial publication.
Missed from PUBLISH method. Is in PUBLISH requirements draft (now expired) REQ10.
Proposes to reuse the content format of the partial notification working order to solve this requirement in PUBLISH.
Alternative is to break published document up between multiple virtual PUAs rather than one actual PUA.
Robert: Suggestion that there may be a different threat model between partial publish and partial notification.
Discussion could not identify an explicit case.
Will call on list within next 4 weeks to see if should be working group item.


MSRP Hop-by-Hop Mechanism
XCAP Open Issues
Event Filtering
Partial Publication