diff --git a/xep-0174.xml b/xep-0174.xml index 01b82daa..6c4948b7 100644 --- a/xep-0174.xml +++ b/xep-0174.xml @@ -25,6 +25,12 @@ N/A &stpeter; + + 0.10 + 2007-03-13 + psa +

Added nick TXT key; added note about use of AAAA records with IPv6; specified that from and to addresses are recommended for stream headers; specified that stream features should be sent.

 + 0.9 2006-12-22 @@ -123,7 +129,7 @@

In order to advertise its availability for link-local messaging, a client MUST publish four different kinds of DNS records:

  1. -

    An address ("A") record of the following form:

    +

    An address ("A" or "AAAA") record of the following form: The IP address MAY be either an IPv4 address or an IPv6 address.

    @@ -148,6 +154,7 @@ _presence._tcp.local. port-number IN PTR username@machine-name._presence._tcp.lo IN TXT "jid=user-jabber-id" IN TXT "last=user-last-name" IN TXT "msg=freeform-availability-status" + IN TXT "nick=user-nickname" IN TXT "phsh=sha1-hash-of-avatar" IN TXT "port.p2pj=5298" IN TXT "status=avail-away-or-dnd" @@ -170,6 +177,7 @@ psa IN TXT "email=stpeter@jabber.org" psa IN TXT "jid=stpeter@jabber.org" psa IN TXT "last=Saint-Andre" psa IN TXT "msg=IETF 66 Montreal" +psa IN TXT "nick=stpeter" psa IN TXT "phsh=a3839614e1a382bcfebbcf20464f519e81770813" psa IN TXT "port.p2pj=5298" psa IN TXT "status=avail" @@ -205,6 +213,10 @@ psa IN TXT "vc=CA!" msg Natural-language text describing the user's state. This is equivalent to the XMPP &STATUS; element. + + nick + A friendly or informal name for the user. + phsh The SHA-1 hash of the user's avatar icon or photo. The client should keep a local cache of icons keyed by hash. If the phsh value is not in the cache, the client should fetch the unknown icon and then cache it. Implementations should also include logic for expiring avatar icons. This SHOULD be requested using mDNS in unicast mode by sending a DNS query to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent FF02::FB). @@ -226,7 +238,7 @@ psa IN TXT "vc=CA!" A flag advertising the user's ability to engage in audio or video conferencing. If the user is able to engage in audio conferencing, the string MUST include the "A" character. If the user is able to engage in video conferencing, the string MUST include the "V" character. If the user is able to engage in conferencing with more than one participant, the string MUST include the "C" character. If the user is not currently engaged in an audio or video conference, the string MUST include the "!" character. The order of characters in the string is immaterial. -

    It is OPTIONAL to include any of these TXT keys, since link-local messaging can be used by non-human entities (e.g., devices) and these keys relate to human users. However, for use by humans, certain keys are of greater interest than others, e.g. the "msg" and "status" keys. See also the Security Considerations section of this document regarding the inclusion of information that may have an impact on personal privacy (e.g., the "1st", "last", "email", and "jid" keys).

    +

    It is OPTIONAL to include any of these TXT keys, since link-local messaging can be used by non-human entities (e.g., devices) and these keys relate to human users. However, for use by humans, certain keys are of greater interest than others, e.g. the "msg" and "status" keys. See also the Security Considerations section of this document regarding the inclusion of information that may have an impact on personal privacy (e.g., the "1st", "last", "nick", "email", and "jid" keys).

    @@ -237,13 +249,30 @@ psa IN TXT "vc=CA!"

    In order to exchange link-local messages, the sender and recipient MUST first establish XML streams between themselves, as is familiar from RFC 3920.

    -

    First, the initating party opens a TCP connection at the IP address and port discovered via the DNS lookup for a local entity and opens an XML stream to the recipient with no 'to' or 'from' address:

    +

    First, the initating party opens a TCP connection at the IP address and port discovered via the DNS lookup for a local entity and opens an XML stream to the recipient, which SHOULD include 'to' and 'from' address:

    + ]]>

    The recipient then responds with a stream header as well:

    + + from='hildjj@wolfram' + to='stpeter@roundabout'> + ]]> +

    The recipient SHOULD also send stream features as specified in RFC 3920:

    + + + + PLAIN + + ]]>

    The exchange of stream headers results in an unencrypted and unauthenticated channel between the two entities. See the Security Considerations section of this document regarding methods for authenticating and encrypting the stream.

     @@ -312,6 +341,6 @@ _presence._tcp.local. IN NULL raw-binary-data-here

    This document requires no interaction with the ®ISTRAR;.

    -

    Thanks to Justin Karneges, Jens Alfke, and Marc Krochmal for their input.

    +

    Thanks to Jens Alfke, Justin Karneges, Marc Krochmal, and Sjoerd Simons for their input.