Re: [Simple] Question about RFC5438 wrt OMA CPM

[Hisham Khartabil <[e-mail]>]

Ben,

I'm trying to make sense of why that last sentence in section 12.1.3.1 was
added (obviously in a later version of the draft).

What you describe is not much different than what I described. The
IMDN-Route value will end up in the Request-URI either way. It will be put
there either by the UAC as part of the "sending" prcedure or by a SIP proxy
on the path. The only minor issue here is that you will have a SIP Route
header carrying the final recepient's URI (which was copied from the IM From
header).th that of X.

After some thinking, I can't find a reason why that sentence in section
12.1.3.1 was placed there. The thinking could've been that this is a new SIP
MESSAGE request and RFC3261 sections 8.1.1.1 and 8.1.1.2 suggests putting
the logical address of the final recipient in there.

In any case, unless someone objects, I have no issue in creating and errata
on RFC5438 striking out that sentence and adding modification text along the
times of what Ben describes the behaviour should be. I don't it makes such
of a difference either way.

Regards,
Hisham

2010/6/5 Ben Campbell <[e-mail]>

> With all due respects to Hisham as an author of the RFC, I have to disagree
> with this position. The described behavior mixes layers between SIP and
> IM/IMDN.
>
> Section 7.2.1, paragraph 4, says:
>
> "If IMDN-Record-Route header fields appear in the IM,
>   the IM Recipient constructing the IMDN MUST copy the contents of the
>   IMDN-Record-Route header fields into IMDN-Route header fields in the
>   IMDN and maintain their order.  The IMDN is then sent to the URI in
>   the top IMDN-Route header field."
>
> So the operative question is what is mean by "send to the URI". In SIP,
> "send to the URI" means to put that URI in the request-URI. Basically we're
> talking about sending a SIP MESSAGE request that is targeted to the IM
> intermediary. Note that such an intermediary is an endpoint from the SIP
> perspective, not a SIP proxy. It is up to that intermediary to forward the
> IMDN by sending a _new_ MESSAGE request to the now top-most IMDN-Route
> value.
>
> Keep in mind there may be any number of SIP proxies between the IMDN sender
> and the IM intermediary, and there may in fact be preloaded SIP Route
> headers pointing to these. But that should have nothing to do with
> IMDN-Route processing.
>
>
> Thanks!
>
> Ben.
>
>
>
>
> On Jun 4, 2010, at 12:56 AM, Hisham Khartabil wrote:
>
> > Not all the URIs in the IMDN-Record-Route, just the 1st one. You then
> follow the procedure in RFC3261 to route the MESSAGE request.
> >
> > 2010/6/4 이승용 <[e-mail]>
> > Hi Hisahm,
> >
> >
> > Thanks for your quick reply.
> >
> >
> > If my understanding is right, you mention that the Request-URI of IMDN is
> populated from the SIP From header of the IM and in addition, route set
> recorded in the IMDN-Record-Route header should be included in the SIP Route
> header in order to guarantee to have IMDN traversed through the SIP Proxies
> whose address was recorded in the IMDN-Record-Route header.
> >
> >
> > My understanding is right?
> >
> >
> > Regards,
> >
> > Seungyong
> >
> >
> >
> > From: Hisham Khartabil [mailto:[e-mail]]
> > Sent: Friday, June 04, 2010 11:43 AM
> > To: 이승용
> > Cc: [e-mail]; [e-mail]; Simple
> WG
> > Subject: Re: Question about RFC5438 wrt OMA CPM
> >
> >
> > Hi,
> >
> > Section 12.1.3.1 does mention that the request-uri and the To header
> field in the IMDN (which is a SIP MESSAGE request) are populated from the
> From header field of the IM (which is a SIP MESSAGE request).
> >
> > This is the initial step. You then need to do some processing.
> >
> > If there are IMDN-Record-Route headers in the payload of the IM, then you
> need to add the 1st URI of that IMDN-Record-Route header field into the
> route set of the IMDN as the last entry (see RFC3261 for route set
> definition). You then need to follow RFC3261 for population of Request-URI
> and Route header fields according to the route set.
> >
> > The route set could be initially empty and therefore the only the uri
> from the IMDN-Record-Route is the only one. Or it could be populated with
> whatever the client has pre-configured (for example, an outbound proxy) and
> therefore the uri is added to the end f that route set.
> >
> > This is normal RFC3261 behaviour.
> >
> > Thanks,
> > Hisham
> >
> > 2010/6/4 이승용 <[e-mail]>
> >
> > Dear Eric Burger, Hisham Khartabil and Christer Holmberg,
> >
> >
> >
> > This is Seungyong Lee from Samsung Electronics and in charge of OMA(Open
> Mobile Alliance) CPM (Converged-IP Messaging).
> >
> > CPM 1.0 supports IMDN for requesting/receiving delivery notifications and
> read reports.
> >
> > In the last CPM meeting (in MAY) there was a heated debate about IMDN
> routing, especially how to populate the Request-URI of IMDN.
> >
> >
> >
> > A delegate from Ericsson argued on the basis of the e-mail thread (see
> http://www.ietf.org/mail-archive/web/simple/current/msg08759.html) that
> the Request-URI of IMDN should be set to the top-most address of
> IMDN-Record-Router header in the received IM where as Samsung retorted that
> the Request-URI is populated from SIP From header of the received IM, which
> is based on section 12.1.3.1 in RFC5438.
> >
> > Section 12.1.3.1 says “…snip… For IMDNs, the IM Recipient populates the
> SIP Request-URI and the SIP To header field using the address that appeared
> in the SIP From header field in the IM.”
> >
> >
> >
> > The routing mechanism of IMDN that I’m thinking of is very similar with
> the SIP routing. That is, Request-URI is populated from SIP From header and
> also SIP Route header is from IMDN-Route header. Because it is SIP headers
> that is used for routing in SIP/IP core, some CPIM headers for IMDN (e.g.
> IMDN Route header) needs to be reflected in SIP headers (e.g. SIP Route
> header).
> >
> >
> >
> > Could you let me know your intended routing scenario from RFC5438
> authors’ perspective?
> >
> > Your quick reply would be so much appreciated and helpful to complete CPM
> 1.0 without delay.
> >
> >
> >
> > Thanks
> >
> > Sincerely,
> >
> >
> >
> > Seungyong Lee
> >
> > Samsung Electronics
> >
> > DMC Research Lab
> >
> > Biz: [phone]
> >
> > E-mail: [e-mail]
> >
> >
> >
> > _______________________________________________
> > Simple mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/simple
>
>