Instant Messaging and Presence Protocol WG (impp)
Wednesday, August 08 at 1300 - 1500
====================================
CHAIRS: Leslie Daigle <leslie@thinkingcat.com>
Mark Day <markday@cisco.com>
AGENDA:
1. Agenda bashing (2 min)
2. Overview of schedule & documents (3 min)
3. Open issues [see summary below](90 min)
a. SRV format ("The DNS thing")
b. FETCH with 0 time
c. CPIM accurate on success vs. refused vs. failure
d. IM use of message/cpim
e. Status of draft-sugano-cpim-pidf-00.txt
f. Role of XMLDSIG and relationship to sugano-cpim-pidf
4. Gatewaying walkthrough report (10 min)
5. Next steps for WG (15 min)
Remaining issues to resolve
===========================
July 16, 2001.
[Issue1] SRV format for identifier resolution
----------------------------------------------
See Christian Huitema's note, in
http://www.imppwg.org/ml-archive/IMPP-WG/200105/msg00016.html
As I understand it, there are 3 ways to go from here:
. provide specific requirements to the DNS (dnsops? dnsext?)
WG, and see waht they have to suggest (see Christian's
note for a suggested list of requirements)
. stop at asking for "where is the <protocol> service
for <some domain>", instead of "where is the IM service
for <some domain> for each of the protocols it supports".
Requires "guessing" and "poking" to determine what services
are supported.
. focus on simply getting the info on the "preferred" IM
service for a particular domain
Which way do we want to go?
Require action:
[Issue2] What about FETCH?
--------------------------
[No discussion since this was posted May 7]
In Minneapolis, the room resolved that subscribe with 0 time does
not unsubscribe. But, see Harald Alvestrand/Hiroyasu Sugano
discussion of April 6, 9:
http://www.imppwg.org/ml-archive/IMPP-WG/200104/msg00008.html
"> So, among the two possible resolutions:
>
> - Zero duration SUBSCRIBE means fetch
> - New operation FETCH, same arguments as SUBSCRIBE except duration
>
> we now have an argument in favour of FETCH.
>
> Query: If FETCH is separate, should the response/NOTIFY be carried in
the
> FETCH answer, or do we want to preserve the separate NOTIFY message?
My preference is that presence info will be carried in the
FETCH response because I expect that a FETCH request is to
acquire the current presence info. I know there is a different
opinion, though.
> Query(2): If FETCH is separate, should SUBSRIBE(duration=0) mean
UNSUBSCRIBE?
As CPIM already has UNSUBSCRIBE operation, the duration value
could be restricted to more than zero. In this case, I think
zero duration SUBSCRIBE should be handled as an error.
Or, we could discard UNSUBSCRIBE... ."
Should we, then:
. create FETCH with status in reply?
. make 0-duration SUBSCRIBE an error?
Resolution:
Required action:
[Issue3] Presence Subscription & privacy
-----------------------------------------
As I understand the conclusion:
SUBSCRIBE returns
. success, or
. operational failure (e.g., congestion)
But "success" means that you have successfully subscribed
to a PRESENTITY, not that you are guaranteed to get
presence information (whether you do or not depends on
the authXXX policies implemented by the server on
behalf of the PRESENTITY).
Resolution: "Yes" -- see 5.1.5 in RFC2779. And we need
a "refused" message that may (or may not -- polite blocking)
be used by servers.
Required action: ensure this is clear in [CPIM]
[Issue4] Where to define IM use of message/cpim?
------------------------------------------------
Proposal: Graham is the only respondant on this -- and suggests it
belongs in CPIM.
Resolution: [CPIM]
Required action: update [CPIM] to reflect it.
[Issue5] Presence XML DTD
--------------------------
We have a proposed XML DTD for presence information,
from Theodore Havinis:
http://www.imppwg.org/ml-archive/IMPP-WG/200104/msg00011.html
and we have (more recently) draft-sugano-cpim-pidf-00.txt which
extends MSGFMT to encompass an XML presence object.
Is the latter
. acceptable
. enough
. ready to be incorporated (by value or by reference) in
CPIM? (Since it seems to include the aspects of
how to apply MSGFMT to the particular application of
presence)?
Resolution:
Required action:
[Issue6] How to carry Presence XML document
-------------------------------------------
If draft-sugano-cpim-pidf-00.txt is acceptable, or at least
people agree it is on the right path, this issue is answered & closed.
Discussion: There has been some discussion on the list re. the
signability of this, as XML is not a bitwise-static (binary)
representation. What's wrong with XMLDSIG, or have I completely
missed the point?
Resolution:
Required action:
[Issue7] Gatewaying walkthrough
--------------------------------
This isn't really an issue; we're waiting for our volunteers
to report back: Jonathan Rosenberg, Vasilis Polychronidis,
Sathya Narayanan.
Any report?
Resolution:
Required action:
Documents -- remaining work
===========================
[CPIM] draft-ietf-impp-cpim
----------------------------
1. Update text to reflect MSGFMT, security requirements for
instant messaging:
"2.3 Format of Instant Messages
An INSTANT MESSAGE comprises a MIME Multipart/Related,
Type=message/RFC822+XML object, as defined in XML/MIME[5].
Representation of non-ASCII character sets in MIME is a standard
feature of MIME.
Note that the IETF provides numerous technologies that allow end-
users to exchange authenticated and private messages formatted as
MIME objects, c.f., PGP-MIME[4] and S/MIME[6]."
Format should be message/cpim, requirement for messaging security
is: reception of multipart/signed for messaging, no requirement to
send signed.
2. Loop detection
Per resolution in Minneapolis, in 2.4.1, include hopcount as part
of abstract parameters for messaging.
3. Identifier resolution, SRVs
Update SRV record section.
Waiting on: [Issue1] -- final resolution of SRV record format
and address resolution. Additional note: example could illustrate
that the targets may be outside the original domain (e.g., pointing
to a gateway)
4. Clarification
>From the mailing list:
"Regardless, there is no application response to the notify operation
(i.e., the application does not invoke a response
operation when a notify operation occurs)."
What does it mean? Does it mean there is no "200 OK" to be expected?
5. To FETCH or not to FETCH
Waiting on: [Issue2]
6. SUBSCRIBE SUCCESS clarification
Waiting on: [Issue3]
7. Define particulars of IMPP's use of message/cpim
for instant messaging
Waiting on: [Issue4]
8. Define particular os IMPP's use of message/cpim
for presence (if applicable)
Waiting on: [Issue5], [Issue6]
[DATETIME] draft-ietf-impp-datetime
------------------------------------
Done (in WG last call)
[MSGFMT] draft-ietf-impp-msgfmt
--------------------------------
1. Administration
Need to define the mechanism for defining new applications.
It's probably as simple as: write an RFC that answers
the questions in section 6.
2. Other todo
Other todo's include those noted by editors ("[[[" "]]]"
encased), including:
"7. IANA CONSIDERATIONS
[[[Registration template for message/cpim content type]]]
[[[Registration of namespace URN for CPIM headers]]]"
The latter is subject to status of IANA URN namespace.