Please confirm (conf#13c4e916c510d6eee0ebbc82d2720924)

<< IMPORTANT INFORMATION! >>

I really hate to do this, but I'm now using an automated
spam-fighting system ("Active Spam Killer") because the 
volume of spam I receive is simply too much to handle
(300+ spam messages a day).

The message you've sent me (attached below) will not be
delivered to me until you confirm that you sent it. To
confirm, just hit the "R"eply button in your email client
and send it back to me (you don't need to edit anything). 
Once this is done, no more confirmations will be necessary.

(Alternatively, you could contact me via the Jabber IM 
network -- see http://www.jabber.org/ for details about
this spam-free alternative to email.)

Again, I really apologize for using an unfriendly system
like this, but email is becoming more of a slum every day
and I need to take protective measures.

Thanks for your patience!

This email account is protected by:
Active Spam Killer (ASK) V2.4.1 - (C) 2001-2002 by Marco Paganini
For more information visit http://www.paganini.net/ask

--- Original Message Follows ---

From: impp <at> iastate.edu

RE: RFC 3861, SRV handling

> Certainly, but what I'm talking about is the server.  Do the 
> RFC 3861 rules apply to delivery between XMPP servers?  It 
> seems to me that the compliant way would be for an XMPP 
> server to first use the RFC 3861 SRV lookup to determine if 
> the destination address supports XMPP.  If that fails, then 
> another protocol (like SIMPLE) could be queried for.  
> However, no existing XMPP servers operate this way, as far as 
> I know, even for those that just support XMPP.

We're shipping one in a couple of weeks.

> So what's the deal here?  Why is the RFC 3861 SRV procedure 
> being ignored?

Because it wasn't needed.

> It seems to me that one of the following has to be true:
> 
> 1) The RFC 3861 SRV procedure is the right way, and XMPP-Core 
> is wrong.
> 
> 2) The XMPP-Core SRV procedure supercedes the RFC 3861 SRV 
> procedure (and therefore the RFC 3861 SRV procedure is wrong, 
> at least within the context of delivering to an XMPP target).
> 
> 3) Both are to be used, perhaps by doing the RFC 3861 SRV 
> lookup first to determine if the destination supports XMPP, 
> followed by doing the XMPP-Core SRV procedure on the result 
> of the RFC 3861 lookup.
> 

RFC 3861, SRV handling

Hi folks,

According to RFC 3861, the destination server of an instant messaging address 
can be determined by doing an SRV lookup on the domain name within that 
address.  For example, if you want to send a message to an address via XMPP, 
one might do a lookup on:

  _im._xmpp.example.com

However, what confuses me is how this is supposed to play with XMPP's own 
delivery procedure, particularly regarding the fact that XMPP uses SRV as 
well.  For example, when one XMPP server delivers a message to another, the 
sending server does an SRV lookup:

  _xmpp-server._tcp.example.com

Should both of these SRV lookups produce the same set of hostname/port pairs, 
meaning that they are two ways to do the same thing and the sender can just 
pick one?  Or should these procedures be "stacked", such that the _im._xmpp 
lookup would result in a domain name that would in turn be passed through the 
_xmpp-server._tcp lookup?

Thank you,
-Justin

  [reminder: meta-impp <at> iastate.edu for non-technical discussions, please]

WG Action: Conclusion of Instant Messaging and Presence Protocol (impp)

The Instant Messaging and Presence Protocol (impp) WG in the Applications Area 
has concluded.

The IESG contact persons are Ted Hardie and Scott Hollenbeck.

The mailing list will remain active.

+++

With the publication of RFCs 3859, 3860, 3861 3862, and 3863, the Instant
Messaging and Presence Protocol working group has concluded. The group's
work in the area of presence data formats and interoperable instant message
formats has seen deployment both in SIMPLE-based and XMPP-based instant
messaging systems and is the basis for additional work in the GEOPRIV
working group. The mailing list will remain open for discussion. The IESG
contact persons are Ted Hardie and Scott Hollenbeck.

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

RFC 3863 on Presence Information Data Format (PIDF)

A new Request for Comments is now available in online RFC libraries.

        RFC 3863

        Title:      Presence Information Data Format (PIDF)
        Author(s):  H. Sugano, S. Fujimoto, G. Klyne, A. Bateman,
                    W. Carr, J. Peterson
        Status:     Standards Track
        Date:       August 2004
        Mailbox:    sugano.h <at> jp.fujitsu.com,
                    shingo_fujimoto <at> jp.fujitsu.com, GK <at> ninebynine.org,
                    bateman <at> acm.org, wayne.carr <at> intel.com,
                    jon.peterson <at> neustar.biz
        Pages:      28
        Characters: 56956
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-impp-cpim-pidf-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt

This memo specifies the Common Profile for Presence (CPP) Presence
Information Data Format (PIDF) as a common presence data format for
CPP-compliant Presence protocols, and also defines a new media type
"application/pidf+xml" to represent the XML MIME entity for PIDF.

This document is a product of the Instant Messaging and Presence
Protocol Working Group of the IETF.

RFC 3862 on Common Presence and Instant Messaging (CPIM): Message Format

A new Request for Comments is now available in online RFC libraries.

        RFC 3862

        Title:      Common Presence and Instant Messaging (CPIM):
                    Message Format
        Author(s):  G. Klyne, D. Atkins
        Status:     Standards Track
        Date:       August 2004
        Mailbox:    GK-IETF <at> ninebynine.org, derek <at> ihtfp.com
        Pages:      30
        Characters: 56133
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-impp-cpim-msgfmt-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3862.txt

This memo defines the MIME content type 'Message/CPIM', a message
format for protocols that conform to the Common Profile for Instant
Messaging (CPIM) specification.

This document is a product of the Instant Messaging and Presence
Protocol Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions

RFC 3861 on Address Resolution for Instant Messaging and Presence

A new Request for Comments is now available in online RFC libraries.

        RFC 3861

        Title:      Address Resolution for Instant Messaging and
                    Presence
        Author(s):  J. Peterson
        Status:     Standards Track
        Date:       August 2004
        Mailbox:    jon.peterson <at> neustar.biz
        Pages:      8
        Characters: 15764
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-impp-srv-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3861.txt

Presence and instant messaging are defined in RFC 2778.  The Common
Profiles for Presence and Instant Messaging define two Universal
Resource Identifier (URI) schemes: \'im' for INSTANT INBOXes and
'pres' for PRESENTITIES.  This document provides guidance for locating
the resources associated with URIs that employ these schemes.

This document is a product of the Instant Messaging and Presence
Protocol Working Group of the IETF.

This is now a Proposed Standard Protocol.

RFC 3859 on Common Profile for Presence (CPP)

A new Request for Comments is now available in online RFC libraries.

        RFC 3859

        Title:      Common Profile for Presence (CPP)
        Author(s):  J. Peterson
        Status:     Standards Track
        Date:       August 2004
        Mailbox:    jon.peterson <at> neustar.biz
        Pages:      15
        Characters: 30537
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-impp-pres-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3859.txt

At the time this document was written, numerous presence protocols
were in use (largely as components of commercial instant messaging
services), and little interoperability between services based on
these protocols has been achieved.  This specification defines common
semantics and data formats for presence to facilitate the creation of
gateways between presence services.

This document is a product of the Instant Messaging and Presence
Protocol Working Group of the IETF.

This is now a Proposed Standard Protocol.

RFC 3860 on Common Profile for Instant Messaging (CPIM)

A new Request for Comments is now available in online RFC libraries.

        RFC 3860

        Title:      Common Profile for Instant Messaging (CPIM)
        Author(s):  J. Peterson
        Status:     Standards Track
        Date:       August 2004
        Mailbox:    jon.peterson <at> neustar.biz
        Pages:      13
        Characters: 26486
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-impp-im-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3860.txt

At the time this document was written, numerous instant messaging
protocols were in use, and little interoperability between services
based on these protocols has been achieved.  This specification
defines common semantics and data formats for instant messaging to
facilitate the creation of gateways between instant messaging
services.

This document is a product of the Instant Messaging and Presence
Protocol Working Group of the IETF.

This is now a Proposed Standard Protocol.

Re:

Re: Document