IMPP - 11/18 19:30 - IETF55 Chairs: Mark Day, Derek Atkins Agenda Bashing (no bashing) Current Draft Status (no comments/questions) Floor comment: PIDF issue - Jonathan Rosenberg - would like to change PIDF to allow zero tuples. Will take request to mailing list. CPIM changes (Jon Peterson) (document split into three) (open issues: loop detection, notification acknowledgement) Jon - Does anyone here think e-e for IM services across gateways should be absolutely mandatory? Mark - we don't need to make people go to the mike immediately Discussion on Loop Detection: Jonathan Rosenberg - would be catastrophic to have a protocol without it. John Ramsdell - Would need this for NOTIFY as well Discussion on Notification Acknowledgement: (Is TransID useful in notification?) Thanos - TransID is useful for detecting duplicates John - Could detect duplicates with timestamps Jon - Timestamps are optional (Should we also have SubscripID?) Mark - Can't include things because it's easy - must have a compelling reason. For SubscripID, that's being able to associate notification with subscription. This also argues against keeping TransID. Jon - Transport could take care of duplicate detection Thanos - Taking TransID out makes mapping to concrete protocols fuzzier. Thanos - Isn't the real issue whether or not Subscriptions need a transaction ID (seems to be consensus around adding SubscripID, some discussion about keeping TransID, Discussion seemed to conclude that TransID could be replaced with SubscripID) Other Issues? --issue-- Thanos - Why not take some of the IM specific 2779 features out of PIDF. Make the IM things inside PIDF and make them a separate profile of PIDF. (Short discussion seemed to be favorable) --issue-- Pekka - Do we need to include a NAPTR resolution instead of just SRV? (notetaker note : I'm not sure I figured out Pekka's question correctly) Jon/Jonathan - the motivations for NAPTR in SIP don't apply to what we're doing in CPIM. Stick with what we have, Pekka - use of SRV is broken/insufficiently specified Mark - would it be sufficient to more clearly specify what to do with the result of an SRV lookup? (Discussion Pekka/Jon seemed to agree) Jonathan - What we have now isn't broken but it should be more explicit about using the resolution mechanisms of the underlying concrete protocols. Dave - What is the real problem being addressed? (Discussion answered: what do you do with an IM URI when you have more than one choice of stack protocols to use to use it.) (Resoulution of im: to something protocol specific belongs to that specific protocol once the protocol has been chosen) Mark - Having just an IP address and port is not enough though - what needs to go into the cpim document to make it sufficient? (Discussion of whether the SRV mechanism is for finding endpoints or gateways. Discussion resolved that it's always finding endpoints - gateways are responsible for knowing that they're gateways). Mark - Is everyone comfortable with what the SRV draft is attempting to do? (Jon believes he understands what the draft needs to do - the change is not to mechanism, it is adding descriptions of what to do with the result of the lookup). Jonathan - need to be sure that all cpim realizations can carry literal pres:/im: URIs - otherwise we find ourselves in NAPTR space. (Discussion of the current mechanism ensued - resolution was that it was OK, Jon is still comfortable with what to do - adding discussion of what to do with the result of an SRV lookup. Mark/Jon verified that the revision of the draft needs to capture Jonathan's above point.) --issue-- John - Need to address 5.1.12 (2779) - How do you authenticate a subscriber across a cpim membrane? Jon - Subscription is different from IM and Notification. Identification for subscriptions can be achieved through transitive authentication. Jonathan - We've addressed this question multiple (4+) times. Do we have any new information that warrants reopening it. (John said no).