Preliminary minutes, IMPP at IETF55

Many thanks to Robert Sparks for being the scribe!

I have fixed a couple of spellings of names and added actions/resolutions
where they were missing.  Comments/corrections to the list, please -- I plan
to send the minutes to the secretariat at the end of the week.

For those not familiar with the players, please note that Jon, Jonathan, and
John in these notes are three different people (Peterson, Rosenberg, and
Ramsdell), not variations of one person's name.

Also note that the apparent resolution of SRV-document issues in the meeting
was illusory, see recent messages on the mailing list.

--Mark

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).




  [reminder: [email protected] for non-technical discussions, please]