Subject: Re: [Stox] I-D Action: draft-ietf-stox-im-04.txt

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 1 Oct 2013 09:38:40 +0200

Hello,
A few random notes:

- Call-ID examples always have a domain in the call id in this draft. As the Call-ID is just a random string, I would prefer either hostname
  to follow the requirements to make it globally unique, or just a random string. I do not want developers to 
  believe that attaching a domain is recommended behaviour.

- Maybe some examples should include international character sets. Julia says

"Jag kommer, Romeo! Din skål jag dricker!"

or Romeo:

"Om jag får sömnens smicker-öga tro,
Så bådar drömmen mig en fröjdfull nyhet."

This is still plain text, but not ASCII...

Table2: (But maybe this is back to core)
- Translation of r-uri to to: header thus overriding the To: header is something worth discussing,
  if it hasn't been discussed yet. The SIP To: header is the original destination of the message,
  and the R-uri is the current target.

Additional notes:

- A SIP MESSAGE can fork. The draft doesn't mention that, something that may have impact
  on implementations. There's a JID on one side - but a forking address on the other side of this spec.
- A SIP MESSAGE can be delivered inside of a dialog and outside of a dialog. Inside of a dialog
   is maybe out of scope for this draft, but in that case the remote target will be a contact address,
   maybe even a GRUU.

/O

1 okt 2013 kl. 08:48 skrev Daniel-Constantin Mierla <[email-masked]>:

> Hello,
> 
> the SIP message example in chapter 4. SIP to XMPP has the From header without tag parameter. Should be like:
> 
> From: <sip:[email-masked]>;tag=xyz
> 
> Daniel
> 
> On 9/30/13 11:56 PM, [email-masked] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>  This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.
>> 
>> 	Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging
>> 	Author(s)       : Peter Saint-Andre
>>                           Avshalom Houri
>>                           Joe Hildebrand
>> 	Filename        : draft-ietf-stox-im-04.txt
>> 	Pages           : 10
>> 	Date            : 2013-09-30
>> 
>> Abstract:
>>    This document defines a bidirectional protocol mapping for the
>>    exchange of single instant messages between the Session Initiation
>>    Protocol (SIP) and the Extensible Messaging and Presence Protocol
>>    (XMPP).
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-stox-im
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-stox-im-04
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-im-04
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> stox mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/stox
> 
> -- 
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Trainings - Berlin, Nov 25-28; Miami, Nov 18-20, 2013
>  - more details about Kamailio trainings at http://www.asipto.com -
> 
> _______________________________________________
> stox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stox

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 02 Oct 2013 15:44:29 -0700

Hej Olle! Thanks for the feedback.

On 10/1/13 12:38 AM, Olle E. Johansson wrote:
> Hello, A few random notes:
> 
> - Call-ID examples always have a domain in the call id in this
> draft.

Also in the presence draft.

> As the Call-ID is just a random string, I would prefer either 
> hostname to follow the requirements to make it globally unique, or 
> just a random string. I do not want developers to believe that 
> attaching a domain is recommended behaviour.

Will fix throughout the document suite (the groupchat I-D has some
examples with Call-ID values that are not globally unique, such as
"711609sa").

> "Om jag får sömnens smicker-öga tro, Så bådar drömmen mig en 
> fröjdfull nyhet."
> 

Not knowing Swedish, I usually use Czech for my examples. :-) But you
make a good point, and I always like to include non-ASCII examples
wherever possible.

> Table2: (But maybe this is back to core) - Translation of r-uri to 
> to: header thus overriding the To: header is something worth 
> discussing, if it hasn't been discussed yet. The SIP To: header is 
> the original destination of the message, and the R-uri is the
> current target.

Yes, I think that belongs in the core I-D.

> Additional notes:
> 
> - A SIP MESSAGE can fork. The draft doesn't mention that,
> something that may have impact on implementations. There's a JID on
> one side - but a forking address on the other side of this spec. -
> A SIP MESSAGE can be delivered inside of a dialog and outside of a
> dialog. Inside of a dialog is maybe out of scope for this draft,
> but in that case the remote target will be a contact address, maybe
> even a GRUU.

Hmm, and here I thought we might be able to discuss forking only in
the media I-D. But I think you're right that we need to discuss it
here, too. What specification has the best coverage of forking? Or is
this part of the "oral tradition" in the SIP community?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 3 Oct 2013 08:32:40 +0200

> this part of the "oral tradition" in the SIP community?

Forking is covered in RFC 3261. Luckily there's no "early text" or that kind of issues
with forking a message - you will only get one 200 OK back (as opposed to INVITE),
which also means you will not see how many destinations that got the MESSAGE.
You can not CANCEL a MESSAGE either. You may get authentication requests as always.

RFC 4328 states:

"When one user wishes to send an instant message to another, the
   sender formulates and issues a SIP request using the new MESSAGE
   method defined by this document.  The Request-URI of this request
   will normally be the "address of record" for the recipient of the
   instant message, but it may be a device address in situations where
   the client has current information about the recipient's location."

So if you have a subscription for registration information on the AOR,
you might select a contact/GRUU to send a message too. 

It also states:

"Note that a downstream proxy could fork a MESSAGE request.  If this
   occurs, the forking proxy will forward one final response upstream,
   even though it may receive multiple final responses.  The UAC will
   have no way to detect whether or not a fork occurs.  Therefore the
   UAC MUST NOT assume that a given final response represents the only
   UAS that receives the request.  For example, multiple branches of a
   fork could have resulted in 2xx responses.  Even though the UAC only
   sees one of those responses, the request has in fact been received by
   the second device as well.
"

All of this makes MESSAGE quite a poor solution for messages you want kept private.
You don't know where it's sent and even if there's authentication on the receiving side,
anyone that gets the unauthenticated request still can access the message unless
of course there's S/MIME involved. 

Well, there was a reason MSRP was developed later. ;-)

/O

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Oct 2013 21:21:36 -0600

>    the second device as well.

Thanks for the clarifications! I'll work to incorporate some of those
insights into the -im document.

> of course there's S/MIME involved. 

Indeed.

> Well, there was a reason MSRP was developed later. ;-)

"If at first you don't succeed..."

Mind you, we've had our share of failed extensions in the XMPP commuity,
too.

Peter