Re: [Stox] stox-presence-03: a couple of comments

[<[e-mail]>]

Hi,

OK. I do recall too that the intent was to put all DNS handling to -core and that has now happened. Thanks, it makes things clearer as there is less overlap between the documents.

Markus 

> -----Original Message-----
> From: ext Peter Saint-Andre [mailto:[e-mail]]
> Sent: 06 September, 2013 04:12
> To: Isomaki Markus (Nokia-CIC/Espoo)
> Cc: [e-mail]
> Subject: Re: [Stox] stox-presence-03: a couple of comments
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 8/26/13 4:49 PM, Peter Saint-Andre wrote:
> > On 8/26/13 6:34 AM, [e-mail] wrote:
> >> Hi,
> >
> > Hi Markus, thanks for the feedback.
> >
> >> I have a couple of comments on the presence-03 draft:
> >>
> >> * Some asymmetry between XMPP-to-SIP (3.2) and SIP-to-XMPP (3.3)
> >> directions
> >>
> >> - 3.2.1 explains the DNS operations an XMPP domain uses to determine
> >> that the foreign domain does not support XMPP but actually supports
> >> SIP/SIMPLE. Presumably something similar is needed in the reverse
> >> direction, but this is not explained in 3.3.1. - The case where the
> >> subscription is rejected is covered in 3.3.1 but not in 3.2.1.
> >
> > Good point. We'll add something about that.
> 
> Actually, I think draft-ietf-stox-core already covers that:
> 
>    When an XMPP service receives an XMPP stanza whose 'to' address
>    specifies or includes a domain other than the domain of the XMPP
>    service, it needs to determine whether the destination domain offers
>    an XMPP service or a SIP service.  To do so, it performs one or more
>    DNS SRV lookups [RFC2782] for "_xmpp-server" records as specified in
>    [RFC6120].  If the response returns a hostname, the service can
>    attempt XMPP communication.  If not, the service can attempt to
>    locate a SIP service for that domain using the procedures specified
>    in [RFC3263].
> 
>    Similarly, when a SIP service receives a SIP message whose Request-
>    URI specifies or includes a domain other than the domain of the SIP
>    service, it needs to determine whether the destination domain offers
>    a SIP service or an XMPP service.  To do so, it uses the procedures
>    specified in [RFC3263].  If that response returns a hostname, the
>    service can attempt SIP communication.  If not, the service can
>    perform one or more DNS SRV lookups [RFC2782] for "_xmpp-server"
>    records as specified in [RFC6120].
> 
> IIRC, we planned to remove such text from all but the core document, since
> it applies to presence, im, chat, groupchat, media, etc.
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJSKSv8AAoJEOoGpJErxa2phm0P/jdOQH+Zev5htJ4QJDA/U3
> bE
> LUO0yN4yXUpfoMXUTzWbwCDPx8kX566zRyhK1uqiOylUVA3hljOfWMc1Fm5
> mj0RS
> nFVUIV8E1sk8mWKvAjsctTuoCQ2Tlk9IfCVLnhP77XX7MoHY8bfU1v20UdwV8y
> Gj
> AU92Bf6bJ/+LFPaZTIS3mxZHCPTTa91pItF0yQF0suwDUtIPJtV1Cz77R6zyqRQG
> 39AdFNUv0FdZ73rS3oeEeZHCcCZctiWdfXr1CRG79h706cfF08Lp3Z8sVi++4Nbp
> Yac6ypzkKmJRmaYVikV6lzkMYAg1muJ5SrBnSj54cRxz/2PYftuK3duvR3CaeCxk
> qx2f45vv2QL0bpZVU2JoINvTZtPB1pfm8PcdDBCbQ0iMkVhRjfy7CJgFbKHlDck
> W
> dhi5kKda2eBiWBcscKs+t33luUi8sKxMj+/1pjCL7gNM54oBKMY/n0XXupVEiikP
> YmFqnBP2LDW3dRIzpY+VdYMQGgS//omdIDPjjEyWBIvepZKrXQpAqKlBHYqEJ
> xaE
> M0laUEvfkzfY1WOkUD7D1b1guiFHQ55i6BK/+KaHk7RibJbp5uqbvAhqY9OVUu
> qZ
> Zt/unJHBl7ONqhlPasbop9nlVRwTGfczuDBBWfiHkJSgjy+wztOcfSuuqMRNEDA
> 8
> pijKmqW3wwEIQ3237F34
> =idjv
> -----END PGP SIGNATURE-----