Subject: [Simple] Some comments for draft-saintandre-xmpp-simple-08

From: Benny Prijono <[email-masked]>
Date: Fri, 08 Sep 2006 14:23:02 +0100

Dear all,

I'd like to give some comments on this draft. In general I think the
document is (or will be) very useful, and I'd like to see it 
progressing further.

Some comments below.

- Use case

The draft says that the use case for XMPP-SIMPLE interoperability is
mainly for gateways, which is defined as "Such a gateway is a
dedicated translator between the XMPP and SIP/SIMPLE protocols. [1.1]".

I don't see that we should limit the use case for dedicated/physical
gateway *server* only. In my view, the translation can also be
performed in user agent clients, for example, when such client
supports both XMPP and SIMPLE in a single application and it needs to
host an IM conference with participants using both protocols.

- Section 3.2, XMPP to SIP

Reading this section, it was not immediately clear to me where the
XMPP-SIP conversion is performed. At first readings, I thought the
conversion is done in destination (example.net) domain, and only after
more careful reading I realized that the conversion is done in source
(example.com) domain.

So perhaps some explicit clarification would help (maybe by saying
something like "the conversion is done by somegw.example.com").

- Still Section 3.2, XMPP to SIP

It shows a SIP message:

    |  MESSAGE sip:[email-masked] SIP/2.0
    |  Via: SIP/2.0/TCP julietpc.example.com;branch=z9hG4bK776sgdkse
    |  Max-Forwards: 70
    |  From: sip:[email-masked];tag=49583
    |  To: sip:[email-masked]
    |  Call-ID: [email-masked]
    |  CSeq: 1 MESSAGE
    |  Content-Type: text/plain
    |  Content-Length: 37
    |
    |  Art thou not Romeo, and a Montague?

Shouldn't the Via contain the address of the gateway, instead of
julietpc?

And (being pedantic) I checked the Content-Length size, it's 35 bytes,
not 37.

- 3.3 SIP to XMPP

Similarly there are some peculiarities in the MESSAGE request sent by
Romeo:

    |  MESSAGE sip:[email-masked] SIP/2.0
    |  Via: SIP/2.0/TCP romeopc.example.com;branch=eskdgs677Kb4Ghz9
    |  Max-Forwards: 70
    |  From: sip:[email-masked];tag=38594
    |  To: sip:[email-masked]
    |  Call-ID: [email-masked]
    |  CSeq: 1 MESSAGE
    |  Content-Type: text/plain
    |  Content-Length: 26
    |
    |  Neither, fair saint, if either thee dislike.

The Via sent-by should be "romeopc.example.net" (not .com), and you'd
better prepend the branch parameter with "z9hG4bK" magic cookie to be
compliant with RFC 3261.

Also the Content-Length is 44, not 26.

- 3.3 Error handling?

Page 11 says:

"If SRV address resolution succeeds, the gateway is
  responsible for translating the request into an XMPP message stanza
  from the SIP user to the XMPP user and returning a SIP "200 OK"
  message to the sender:"

Reading this paragraph, I've got the impression that the gateway
should send 200/OK unconditionally. Perhaps somewhere in this section
it should mention about possible errors and the mapping of such errors
in section 7.

- 4 Presence Subscriptions

I think probably the document could do some restructurization, and
spesificly it should discuss these issues as separate sections:

  a. establishing subscription
  b. refreshing subscription
  c. canceling subscription

And in *both* directions (XMPP to SIP and SIP to XMPP). Maybe some of
these probably don't make sense in the XMPP side, but they are very
important for the SIP side, thus I feel they deserve explicit discussions.

- 4.2 (Presence) XMPP to SIP

Again I'm having difficulty in understanding *where* the XMPP to SIP
conversion should be performed (when sending initial SUBSCRIBE
request). Reading the paragraph, it sounds like the conversion is done
by a gateway in source domain (example.com), but the Via address in
the SUBSCRIBE request contains "simple.example.net", which is in
destination domain.

I think the Via address should be "simple.example.com" instead.

Looking at the 200/OK response (page 14), it looks like the tag in the
 From header gets swapped to the To header, which is wrong. The 200/OK
response MUST have the same tag in the From header, and in addition,
it also MUST contain a unique tag in the To header.

Also looking at both SUBSCRIBE request and response, I don't see why
we should put ";maddr" parameter in the Contact headers. If this
denotes some significance, then we should explain why do we need this,
or otherwise I suggest that we just remove it altogether.

- Still in 4.2

The draft says that (when performing presence conversion from XMPP to
SIMPLE) the gateway should set XMPP presence to "subscribed" as soon
as it receives 200/OK response to SUBSCRIBE.

I'm not sure about the semantic of "subscribed" in XMPP, but in
SIMPLE, 200/OK response to SUBSCRIBE doesn't necessarily mean that
presence subscription has been established (RFC 3265 says that the
state is "neutral" at this point). Subscription is only confirmed in
the NOTIFY request when Subscription-State is "active".

- Section 4.3 Handling SIP user's subscription expires

I don't understand the long-lived options when SIP subscription
expires (which one is long lived, the XMPP side or the SIP side?). But
in any case, the gateway SHOULD send NOTIFY with Subscription-State
set to terminated and definitely it does not send SUBSCRIBE to the
user (unless I misunderstood your intention).

- Briefly looking at the rest of section 4

Again I feel that the document could do better restructurization, by
dividing the sections into subscription state as seen by the SIP side
and XMPP side.

Looking briefly at some of the SIP messages, I see that some NOTIFY
are missing Subscription-State header, which is mandatory.

I haven't read section 5 and beyond, I'll post more comments when I
read it.

thanks,
-benny

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 11 Sep 2006 16:24:50 -0600

Thanks for the feedback. Comments inline.

Benny Prijono wrote:
> document is (or will be) very useful, and I'd like to see it progressing
> further.
> 
> Some comments below.
> 
> - Use case
> 

True, the same principles would apply to protocol transformation in a
user agent. I'll make the text more neutral. Probably we were trying to
give readers an architecture they could hang their hats on.

> something like "the conversion is done by somegw.example.com").

Good point, I'll clarify that. In fact, an architectural diagram in
Section 1.1 would be helpful.

> Shouldn't the Via contain the address of the gateway, instead of

Yes.

> And (being pedantic) I checked the Content-Length size, it's 35 bytes,

Heh, pedantry is good. :-) I haven't checked those in a while.

> The Via sent-by should be "romeopc.example.net" (not .com), 

Or simplegw.example.net perhaps?

> and you'd

Will fix.

> it should mention about possible errors and the mapping of such errors

OK, I'll add that.

> important for the SIP side, thus I feel they deserve explicit discussions.

You're right.

> I think the Via address should be "simple.example.com" instead.

Yes, it should.

> it also MUST contain a unique tag in the To header.

OK, will fix.

> or otherwise I suggest that we just remove it altogether.

Perhaps I unthinkingly copied an example from a real SIP document, but
I'll double-check.

> the NOTIFY request when Subscription-State is "active".

I'll check into that. XMPP subscribed has the same meaning as NOTIFY
with Subscription-State of "active", so the meanings translate well, but
the current examples or text may be wrong.

> user (unless I misunderstood your intention).

The long-lived is on the XMPP side. I'll review this again.

> I haven't read section 5 and beyond, I'll post more comments when I

Thanks, I appreciate your close reading.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml