NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Harald Alvestrand <alvestrand@cisco.com>
Leslie Daigle <leslie@thinkingcat.com>
Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>
Patrik Faltstrom <paf@cisco.com>
General Discussion:impp@iastate.edu
To Subscribe: impp-request@iastate.edu
Archive: http://www.imppwg.org
This working group will eventually define protocols and data formats necessary to build an internet-scale end-user presence awareness, notification and instant messaging system. Its initial task is to determine specific design goals and requirements for such a service. The design goals document will be submitted for IETF-wide review, and based on that review, the group's charter will be extended.
Background:
Instant messaging differs from email primarily in that its primary focus is immediate end-user delivery. Presence information was readily accessible on internet-connected systems years ago; when a user had an open session to a well-known multi-user system, his friends and colleagues could easily tell where he was connected from and whether he was using his computer. Since that time, computing infrastructure has become increasingly distributed and a given user may be consistently available," but has no standard way to make this information known to her peers. This working group will design a system to address this need.
Goals:
The working group will develop an architecture for simple instant messaging and presence awareness/notification. It will specify how authentication, message integrity, encryption and access control are integrated. It is desirable, but not required, for the working group to develop a solution that works well for awareness of and communication with entities other than human users.
Non-goals:
Providing a general notification mechanism for data other than user presence information and instant messages.
The following keywords describe the scope for the working group. Details are to be developed in the architecture document which is the output of this working group:
- PRESENCE
- INSTANT MESSAGING
- SHARED
- NAMING
- AUTHENTICATION
- ACCESS CONTROL
- SCALABILITY
Deliverables:
The working group plans to deliver the following document:
- Requirements for Instant Messaging and Presence
Done |
|
Submit Internet-Draft of Design Goals for Instant Messaging and Presence Information |
Done |
|
Submit design goals Internet-Draft to IESG for publication as an RFC |
Feb 01 |
|
Submit I-D on common instant message format |
Mar 01 |
|
Meet at 50th IETF in Minneapolis |
Apr 01 |
|
Submit Common Presence and Instant Messaging document and Common Instant Message Format to IETF for consideration as Proposed Standard |
May 01 |
|
Upon publication of RFCs, close group. |
RFC |
Status |
Title |
RFC2778 |
A Model for Presence and Instant Messaging | |
RFC2779 |
Instant Messaging / Presence Protocol Requirements |
Instant Messaging and Presence (IMPP) Working Group
Meeting -- IETF50 -- Monday, March 19, 2001, 15:30-17:30
Official note-taker: Derek Atkins
Agenda
------
Agenda bash
Archictectural Open Issues
CPIM nits (draft-ietf-impp-cpim-01.txt)
MSGFMT nits (draft-ietf-impp-cpim-msgfmt-00.txt)
AOB
No issue with the agenda, so we proceed with working over identified issues.
---------------
Issue: Security, mandatory to implement
Proposal: reception of multipart/signed
sending of s/mime multipart/signed
Dave Crocker: Choosing S/MIME over PGP/MIME is not a wise solution; given S/MIME has not been deployed through the internet. It is counter-productive to choose one particular method.
Christian Huitema: Strong proof that if you use XML, do you want to use MIME security with XML or XML Security? It's not obvious that you want to use signed mime vs. signed xml.
This requirement should be clarified; should say "for messaging"
Resolution
reception of multipart/signed for messaging
no requirement to send
-------------------
Issue: Routing Loop prevention
Proposal: hop-count decrement
requires hopcount not in signed portion.
Christian: Doesn't make sense to specify unless it's part of the standard interface?
Harald Alvestrand: Add to interface the number of hops a message may go through before it is dropped. In the 'abstract envelope' this is the number of hops a message may go through.
Resolution: in CPIM 2.4.1, include as part of abstract parameters for messaging.
-------------------
Issue: Standard Date Format
Proposal: do we need one?
Resolution: yes
Proposal: rfc1123 (GMT only) v. iso?
Dave Crocker: Implementation experience of rfc1123 v. iso-string?
What experience is there?
??: Important to express "I will be here until 5pm tonight". Must be able to express this, not have to do the math to figure GMT.
Resolution: ISO, leverage Chris Newman's work. Call it "date-time" (after both hum and hands)
--------------------
Issue: Payload content for (common) presence information
Proposal:
- presentity URL
- list of contact URLs
- - status (open,closed)
- - timestamp
- - human readable comment
- - relative priority
- presentity human readable comment - independent of any contact
- URL - like a reference to a picture of a smilery face or something
- Extensibility
Question: geographic info?
What is the difference of text vs. URLs?
We'd say that the text was going to be displayed
"This is a URL that represents the graphical representation of the presentity"?
URLs are used for lots of different things. Present it in UI?
Not a huge difference in rendering text v. rendering URL.
Put URL into extensions?
Leave text-field in?
What about including geo info in standard attrs?
Resolution:
Smiley-URL to extensions
Geo into extension
Question: is it important for geo for IM? Yes to some, no to others.
But this is generic presence.
------------------------
Issue: Payload format for presence info?
Proposal:
MSGFMT/RFC822 stle?
or
XML?
or
leave it abstract, no security end-to-end
No security is counter to rfc2779.
Using msgfmt could include an xml document.
Middle-ground is that there is a msgfmt wrapper with To,From with presence info inside, right? No, just using the msgfmt context without all the cpim headers?
Perhaps the only header is the signer?
The 'From' of the message is not necessarily the signator.
Problem with where the content/content header segment start and where they end.
No problem with the end of a message, but there is a problem with nesting.
Resolution: XML
How do we ship it around?
Notify operation (3.4.2) has the presentity as one of its parameters.
More questions: Carry it is MSGFMT? Raw MIME Type? Security? Need more careful thought. In particular, how much of the transport format should we specify, and how, in order to meet security requirements?
>From the first group-of-nine discussion, we agreed that we were not going to have multiple subsciptions for the same presentity. (You have local fanout).
Discuss offline and bring it back to the list.
This needs experimentation.
Resolution: XML-DTD for Presence document. Dave Crocker?
Vasilis Polychronidis (@openwave) volunteered.
-------------------
Issue: Address resolution in multiprotocol context
Proposal:
SRV at edge?
NAPTR at edge?
How would NAPTR records be used?
Weight/Priority
Flags to control the process
Services: end point differentiation
Regexp: end point identifier "factory"
Replacement: (a DNS shortcut if regex is just domainname)
Additional info section contains the SRV and A records
Michael Mealling presents a brief overview of how NAPTR might be applied to the situation. Some concerns from the floor that NAPTR are expressive and potentially quite complex. The counter argument is that the CPIM application would define a very restrictive application of their use (as does ENUM).
Now that NAPTR was explained and discussed, return to the question, do we want to go with some variant of SRV or NAPTR?
General feeling of the room is that the potential of NAPTR doesn't buy enough over SRV, and the concern over additional complexity remains.
Resolution: Use SRV records for first-round lookups:
_<proto>._im.domain. (e.g. _simple._im.domain.)
Christian will make proposal for revised CPIM text
------------------
Issue: Gatewaying
General discussion of the gatewaying issue:
Problem when you don't separate the transport address from the message recipient address?
Problem: start with generic im/pres url, chuck it, and then you need to reconvert back up to generic to get "out" of the system.
If you've thrown away information then you are in trouble.
For forwarding, it must either be a local issue, or you forward to an im/pres URI.
Have two strings? One string provided by sender, and another provided from the last transport hop.
This is related to how IP packets are forwarded across different physical media?
Original Destination by Original Sender (Im/pres)
Two addrs at each hop:
global received
local resolved
>From the amount of discussion, it is clear that there are places where more refinement in the existing documents may be necessary, and certainly shared experience would be quite useful.
Resolution: will do walk through illustrations
Volunteers: Jonathan Rosenberg, Vasalis Polychronidis (Presence); player to be named later for co-im.
-------------------
Nits in docs
What about FETCH?
Subscribe with 0 time does not unsubscribe
Proposal: support explicity subscription ID
Proposal: explicit fetch operations, current state returned
Resolution: clarification of zero-duration subscribe; it does the fetch (CPIM 3.4.3)
--------------------
Issue: resubscribe?
Proposal: change the "failure" for subscribing again to
"instant resubscribe" (extension or reduction of subscription time limit)
At this point, discussion was brought to a close -- more issues were being brought up than we could thoughtfully cover in the meeting.
As an administrative note, Leslie Daigle mentioned that Harald has announced his intention to step down as co-chair of IMPP as his plate is quite full with his new appointment as IETF Chair. A new co-chair is being sought. Congratulations & thanks Harald.
None received.