headers
Robert Sparks | 2 Feb 2007 17:35
Favicon

WG -00 preapproval

The secretariat is asking for WG chair preapproval of any new WG -00  
drafts in a couple of weeks.

I don't think we have any new SIMPLE -00's in the works. If I have  
forgotten something, please remind me ASAP.

This doesn't apply to individual -00s, only those that start out  
draft-ietf-simple-

Thanks,

RjS
Permalink | Reply | 0 comments |
headers
Tiago | 4 Feb 2007 20:29
Picon

XCAP PUT Validation: Not UTF-8

Hi, how exactly works the validation that the content's enconding in a XCAP PUT operation is UTF-8? Is there any public domain Java class that does this?

Thanks in advance,

Tiago

_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www1.ietf.org/mailman/listinfo/simple
Permalink | Reply | 0 comments |
headers
Hisham Khartabil | 5 Feb 2007 01:56
Picon

Re: WGLC: draft-ietf-simple-imdn-02.txt

Hi Miguel

Thanks for your comments. Some replies inline...

On 21/12/06, Miguel Garcia <Miguel.An.Garcia <at> nokia.com> wrote:
> Here are my comments to IMDN-02.txt

>
> Delete completely Section 13.

I will not. The text in there lets readers that  we thought about msrp.

>
>
> - Comment in the terminology (Section 3). The 'IM Sender' definition
> indicates that the IM Sender might be different from the IMDN recipient.
> Doesn't this create a security threat by allowing endpoints to redirect
> IMDNs to third parties?

This text is in there to indicate that resolving someone's AoR when
sending the IMDN may in fact result in a different User Agent. The
text does not suggest that an IM recipient may change the IM Sender
address when sending IMDNs (although we cannot control that). I'll
clarify.

>
> - Terminology, Section 3. I would suggest to decouple the IMDN payload
> from the fact that is an XML document of MIME type message/imdn+xml,
> because in the future you could create other MIME types, and still be an
> IMDN payload. So I would suggest to replace:
>
>     o  IMDN Payload or XML Document: An XML document carrying the
>        disposition notification information.  It is always of MIME type
>        "message/imdn+xml".
>
> with:
>
>     o  IMDN Payload: An document, typically an XML document, carrying the
>        disposition notification information.

I would like to keep it as xml, but i will soften the "always" part.

>
> - Section 5.3. We could think of use the term "rendered" rather than
> "read".

This change is huge and way too late, imo. I'll add clarifying text
but will not change the whole draft.

> - General question, not tied to any section. What happens if the IM
> sender has several devices or SIP instances, sends an IM and requests
> IMDN? The desired effect is that IMDNs are received in the same device
> where the IM was sent out. This is calling for something like GRUU, but
> I don't think we can use GRUU in MESSAGE requests. It would be nice to
> either have a solution or just write the limitations of the
> specification with respect several devices/instances.

This is mentioned in the draft, but is not called for as a limitation.
I can indicate that it is a limitation.

Thanks,
Hisham
Permalink | Reply | 0 comments |
headers
Miguel Garcia | 5 Feb 2007 11:38
Picon

Comments to draft-stafford-simple-dmdn-00.txt

Hi:

So, a summary of draft-stafford-simple-dmdn is  that there is a use case 
that is not covered by the current IMDN, which is:

- An MSRP session is intercepted by a store-and-forward server. The 
sender would like to be informed when the final recipient receives or 
reads the message(s).

One first question about the use case. It appears form the text in the 
draft that the use case applies only to large messages. However, I can 
envision store-and-forward servers that store a complete MSRP session 
(not only ONE large message).

I think it is important to consider these collections of MSRP messages, 
because, imagine we add something to the CPIM headers of each MSRP SEND 
requesting delivery disposition notification, then the sender will 
receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND 
request. I guess this is not reasonable.

On the other hand, if there isn't a store-and-forward server in the 
path, then there is no need for the sender to receive additional 
notifications, because the success reports in MSRP will do the job.

So, I guess where we are going is to get some sort of conditional IMDN 
for MSRP. The condition being the unavailability of the recipient to get 
the messages and a store-and-forward server storing them. This will 
obviously apply to either large messages or short ones.

Any views on this?

BR,

      Miguel
--

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.garcia <at> neonsite.net
Nokia Research Center      Helsinki, Finland
Permalink | Reply | 12 comments |
headers
Salvatore Loreto (JO/LMF | 5 Feb 2007 13:14
Picon
Favicon

RE: Internal WG Review: Recharter of SIP forInstantMessaging and Presence Leveraging Extensions (simple)

Hi,

-how continue (or better change) a conversation triggered by a MESSAGE
in a new MRSP session

-issues related to MRSP sessions established for just sending one
message (e.g. imdn or similar functionality)

I do think that both the issues summarized above (and mentioned in the
previous mails) are problems that SIMPLE should try to address.

br
sal

On Wed, 2007-01-31 at 08:48 -0600, Stafford, Matthew wrote:
> Re wireless service providers wanting something similar to MMS: I would
> say not only in its own right, but as an interworking vehicle with the
> MMS installed base. This is important, I think, from the POV of
> facilitating SIMPLE deployment- something I would very much like to see!
> 
> In the context of this conversation, I am eager to hear comments on an
> internet draft posted a couple of weeks ago:
> http://www.ietf.org/internet-drafts/draft-stafford-simple-dmdn-00.txt
> 
> The draft sets forth use cases involving MSRP- use cases in which imdn
> (or similar) functionality would be very useful. In many instances, use
> cases can be supported with existing building blocks. But here we do see
> a gap, and think that the best solution would be a new/extended building
> block devised by IETF. As I indicated in a Jan 19 message posted to this
> list, we understand the need to go ahead and progress the imdn draft
> (sans MSRP).
> 
> I'm not necessarily inviting detailed discussion of this draft (in the
> midst of the current rechartering discussion, that might be premature).
> At this point, I'm wanting to know whether this sort of thing will be in
> scope (and "lobbying" for the answer to be yes...)
> 
> Best,
> Matt Stafford 
> 
> -----Original Message-----
> From: Markus.Isomaki <at> nokia.com [mailto:Markus.Isomaki <at> nokia.com] 
> Sent: Wednesday, January 31, 2007 3:37 AM
> To: pkyzivat <at> cisco.com; simple <at> ietf.org
> Subject: RE: [Simple] Internal WG Review: Recharter of SIP
> forInstantMessaging and Presence Leveraging Extensions (simple)
> 
> Hi,
> 
> Yes, I think this is a feature that would be needed in practice. Having
> two messaging mechanisms without clear guidance on how they relate to
> each other is going to cause interoperability issues - if not on the
> protocol level then at least on the UI-to-UI or user-to-user level.
> 
> Another thing is that there should be some kind of
> specification/guideline on how to actually deliver one-shot messages
> that are larger than 1300 bytes. One way is to use MSRP, another to do
> content indirection with MESSAGE. In MSRP the key is the ability for the
> sender to indicate (at least as a preference/hint) that the session is
> established for just sending a single message, not to open a
> conversation. This is wanted by providers who would like to be able to
> offer something similar to MMS service on top of a SIP infra. 
> 
> SIMPLE WG has not been very enthusiastic about this in the past, so I
> think OMA has already defined a particular mechanism for MSRP. If
> everyone who is interested in this is anyway involved in OMA, as it
> seems, there would be not much value for IETF to do anything about it.
> However, if there is real interest outside OMA, it would be useful to
> have some work in SIMPLE WG.
> 
> Markus
>  
> 
> >-----Original Message-----
> >From: ext Paul Kyzivat [mailto:pkyzivat <at> cisco.com] 
> >Sent: 31 January, 2007 00:15
> >To: simple <at> ietf.org
> >Subject: Re: [Simple] Internal WG Review: Recharter of SIP for 
> >InstantMessaging and Presence Leveraging Extensions (simple)
> >
> >Wasn't there some talk of a need to specify how to choose 
> >between MESSAGE and MSRP, and/or to transition between them in 
> >support of a single conversation?
> >
> >E.g. send a MESSAGE because there may never be a conversation, 
> >but then INVITE with an MSRP session to continue the 
> >conversation. The need here would be for a way to tie these 
> >things together so it is clear that they are part of the same 
> >conversation. There are obviously issues with involving the 
> >same pair of UAs in both.
> >
> >I seem to recall this was discussed at some point, but I'm not 
> >sure and if so I don't remember the outcome.
> >
> >	Paul
> >
> >IESG Secretary wrote:
> >> A new charter for the SIP for Instant Messaging and Presence 
> >> Leveraging Extensions (simple) working group in the Real-time 
> >> Applications and Infrastructure Area of the IETF is being 
> >considered. 
> >> The draft charter is provided below for your review and comment.
> >> 
> >> Review time is one week.
> >> 
> >> The IETF Secretariat
> >> 
> >> +++
> >> 
> >> SIP for Instant Messaging and Presence Leveraging Extensions 
> >(simple) 
> >> 
> >======================================================================
> >> 
> >> Last Modified: 2007-1-24
> >> 
> >> Current Status: Active Working Group
> >> 
> >> Chair(s):
> >> Robert Sparks <RjS <at> estacado.net>
> >> Hisham Khartabil <hisham.khartabil <at> gmail.com>
> >> 
> >> 
> >> Real-time Applications and Infrastructure Area Director(s):
> >> Jon Peterson <jon.peterson <at> neustar.biz> Cullen Jennings 
> >> <fluffy <at> cisco.com>
> >> 
> >> Real-time Applications and Infrastructure Area Advisor:
> >> Jon Peterson <jon.peterson <at> neustar.biz>
> >> 
> >> Technical Advisor(s):
> >> Jon Peterson <jon.peterson <at> neustar.biz>
> >> 
> >> Mailing Lists:
> >> General Discussion: simple <at> ietf.org
> >> To Subscribe: simple-request <at> ietf.org
> >> In Body: subscribe
> >> Archive: http://www.ietf.org/mail-archive/web/simple/index.html
> >> 
> >> Description of Working Group:
> >> 
> >> This working group focuses on the application of the Session 
> >> Initiation Protocol (SIP, RFC 3261) to the suite of services 
> >> collectively known as instant messaging and presence (IMP). The IETF 
> >> has committed to producing an interoperable standard for these 
> >> services compliant to the requirements for IM outlined in RFC 2779 
> >> (including the security and privacy requirements there) and in the 
> >> Common Presence and Instant Messaging (CPIM) specification, 
> >developed 
> >> within the IMPP working group. As the most common services for which 
> >> SIP is used share quite a bit in common with IMP, the adaptation of 
> >> SIP to IMP seems a natural choice given the widespread support for 
> >> (and relative maturity of) the SIP standard.
> >> 
> >> This group has completed the majority of its primary goals and will 
> >> focus on the remaining tasks documented here and concluding. Any 
> >> proposed new work should be socialized with the chairs and 
> >AD early to 
> >> determine if this WG is an appropriate venue.
> >> 
> >> The primary remaining work of this group will be to complete:
> >> 
> >> 1. The MSRP proposed standard mechanism for transporting sessions of 
> >> messages initiated using the SIP, compliant to the 
> >requirments of RFC 
> >> 2779, CPIM and BCP 41.
> >> 
> >> 2. The XCAP framework for representing and carrying 
> >configuration and 
> >> policy information in SIMPLE systems.
> >> 
> >> 3. A mechanism for representing partial changes (patches) to XML 
> >> documents and extensions to the SIMPLE publication and notification 
> >> mechanisms to convey these partial changes.
> >> 
> >> 4. A mechanism for initiating and managing Instant Message 
> >group chat.
> >> 
> >> 5. An annotated overview of the SIMPLE protocol definition documents.
> >> 
> >> Any SIP extensions proposed in the course of this development will, 
> >> after a last call process, be transferred to the SIP WG for 
> >> consideration as formal SIP extensions.
> >> 
> >> Any mechanisms created for managing Instant Message group chat are 
> >> intended to provide a bridge to the conferencing protocols that will 
> >> be defined in XCON. They will be limited in scope to address only 
> >> simple Instant Message chat with nicknames and will not attempt to 
> >> address complex conferencing concepts such as sidebars. Their design 
> >> must anticipate operating in conjunction with the conferencing 
> >> protocols XCON is working towards.
> >> 
> >> The working group will work within the framework for presence and IM 
> >> described in RFC 2778. The extensions it defines must also be 
> >> compliant with the SIP processes for extensions. The group cannot 
> >> modify baseline SIP behavior or define a new version of SIP 
> >for IM and 
> >> presence. If the group determines that any capabilities requiring an 
> >> extension to SIP are needed, the group will seek to define such 
> >> extensions within the SIP working group, and then use them here.
> >> 
> >> Goals and Milestones:
> >> Done Submission of event package for presence to IESG for 
> >publication 
> >> as Proposed Standard Done Submission of watcher information 
> >drafts to 
> >> IESG for publication as Proposed Standards Done Submission 
> >of proposed 
> >> event list mechanism to the SIP working group Done Submission of 
> >> requirements for event publishing to the IESG for publication as 
> >> Proposed Standard Done Submission of proposed mechanism for event 
> >> publishing to the SIP working group Done Submission of SIMPLE PIDF 
> >> profile to IESG for publication as Proposed Standard Done Submission 
> >> of base XCAP draft to IESG for publication as Proposed Standard Done 
> >> Submission of indication of instant message preparation using SIP to 
> >> IESG for publication as a Proposed Standard Done Submission of XCAP 
> >> usage for manipulation of presence document content Done 
> >Submission of 
> >> XCAP usage for setting presence authorization to IESG for 
> >publication 
> >> as Proposed Standard Done Submission of Filtering mechanisms to IESG 
> >> for publication as a Proposed Standard Done Submission of instant 
> >> messaging session draft to IESG for publication as a 
> >Proposed Standard 
> >> Done Submission of instant messaging session relay drafts to 
> >IESG for 
> >> publication as Proposed Standards Done Submission of Partial 
> >> Notification mechanism to IESG for publication as a Proposed 
> >Standard 
> >> Feb 2007 Submission of an Instant Message Disposition Notification 
> >> mechanism to the IESG for publication as a Proposed Standard 
> >Feb 2007 
> >> Submission of XCAP event package to IESG or appropriate 
> >working group 
> >> targeting publication as Proposed Standard Feb 2007 Submission of 
> >> proposed mechanisms meeting the advanced messaging 
> >requirements to the 
> >> IESG or appropriate working group Mar 2007 Submission of a 
> >performance 
> >> and scalability analysis of the SIMPLE presence mechanisms 
> >to the IESG 
> >> for publication as Informational Jun 2007 Submission of SIMPLE 
> >> protocol annotated overview draft to IESG for publication as 
> >> Informational Aug 2007 Submission of proposed mechanisms for 
> >> initiating and managing Instant Message group chat to the IESG for 
> >> publication as Proposed Standard Aug 2007 Conclusion of SIMPLE
> >> 
> >> _______________________________________________
> >> Simple mailing list
> >> Simple <at> ietf.org
> >> https://www1.ietf.org/mailman/listinfo/simple
> >> 
> >
> >_______________________________________________
> >Simple mailing list
> >Simple <at> ietf.org
> >https://www1.ietf.org/mailman/listinfo/simple
> >
> 
> _______________________________________________
> Simple mailing list
> Simple <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 
> _______________________________________________
> Simple mailing list
> Simple <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
Permalink | Reply | 1 comment |
headers
Salvatore Loreto (JO/LMF | 5 Feb 2007 14:02
Picon
Favicon

Re: Comments to draft-stafford-simple-dmdn-00.txt

Hi ,

some comments in line

br
/sal

On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote:
> Hi:
> 
> So, a summary of draft-stafford-simple-dmdn is  that there is a use case 
> that is not covered by the current IMDN, which is:
> 
> - An MSRP session is intercepted by a store-and-forward server. The 
> sender would like to be informed when the final recipient receives or 
> reads the message(s).
> 
> One first question about the use case. It appears form the text in the 
> draft that the use case applies only to large messages. However, I can 
> envision store-and-forward servers that store a complete MSRP session 
> (not only ONE large message).

you are right, if you have a store-and-forward in the path this is a
possible scenario, even if I can not imagine at present a specific use
case. (e.g. Why someone would establish a MSRP session with an off-line
user and start to chat with him?)
> 
> I think it is important to consider these collections of MSRP messages, 
> because, imagine we add something to the CPIM headers of each MSRP SEND 
> requesting delivery disposition notification, then the sender will 
> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND 
> request. I guess this is not reasonable.

I agree. 
A solution could be that the store-and-forward server collect all the
message in one single big message, but in this case it shouldn't be any
more a simple store-and-forward.

> 
> On the other hand, if there isn't a store-and-forward server in the 
> path, then there is no need for the sender to receive additional 
> notifications, because the success reports in MSRP will do the job.
> 
> So, I guess where we are going is to get some sort of conditional IMDN 
> for MSRP. The condition being the unavailability of the recipient to get 
> the messages and a store-and-forward server storing them. This will 
> obviously apply to either large messages or short ones.

I don't have a clear view on this,
but maybe if we introduce a indication that an MRSP session is
established for just sending one message, this indication could help.

> Any views on this?
> 
> BR,
> 
>       Miguel
Permalink | Reply | 11 comments |
headers
Shih, Jerry | 5 Feb 2007 14:11

RE: Comments to draft-stafford-simple-dmdn-00.txt

Actually, in OMA LARGE message definition, it is a one direction
(send-only) session, not really a regular MSRP session; so no chat in
this case. It is used as a one-shot message and the only reason it needs
to set-up a session is because it is over the MESSAGE method size. The
sending UE knows (but the user will not know that) that it is a one-time
message when it sets up the session (send-only).

Jerry Shih
Cingular Wireless, now the new AT&T
+1 404.236.5902 (Office)
+1 678.925.3568 (Mobile)

-----Original Message-----
From: Salvatore Loreto (JO/LMF) [mailto:salvatore.loreto <at> ericsson.com] 
Sent: Monday, February 05, 2007 8:02 AM
To: Miguel Garcia
Cc: 'simple <at> ietf.org'
Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

Hi ,

some comments in line

br
/sal

On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote:
> Hi:
> 
> So, a summary of draft-stafford-simple-dmdn is  that there is a use
case 
> that is not covered by the current IMDN, which is:
> 
> - An MSRP session is intercepted by a store-and-forward server. The 
> sender would like to be informed when the final recipient receives or 
> reads the message(s).
> 
> One first question about the use case. It appears form the text in the

> draft that the use case applies only to large messages. However, I can

> envision store-and-forward servers that store a complete MSRP session 
> (not only ONE large message).

you are right, if you have a store-and-forward in the path this is a
possible scenario, even if I can not imagine at present a specific use
case. (e.g. Why someone would establish a MSRP session with an off-line
user and start to chat with him?)
> 
> I think it is important to consider these collections of MSRP
messages, 
> because, imagine we add something to the CPIM headers of each MSRP
SEND 
> requesting delivery disposition notification, then the sender will 
> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND 
> request. I guess this is not reasonable.

I agree. 
A solution could be that the store-and-forward server collect all the
message in one single big message, but in this case it shouldn't be any
more a simple store-and-forward.

> 
> On the other hand, if there isn't a store-and-forward server in the 
> path, then there is no need for the sender to receive additional 
> notifications, because the success reports in MSRP will do the job.
> 
> So, I guess where we are going is to get some sort of conditional IMDN

> for MSRP. The condition being the unavailability of the recipient to
get 
> the messages and a store-and-forward server storing them. This will 
> obviously apply to either large messages or short ones.

I don't have a clear view on this,
but maybe if we introduce a indication that an MRSP session is
established for just sending one message, this indication could help.

> Any views on this?
> 
> BR,
> 
>       Miguel

_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www1.ietf.org/mailman/listinfo/simple
Permalink | Reply | 0 comments |
headers
Miguel Garcia | 5 Feb 2007 14:17
Picon

Re: Comments to draft-stafford-simple-dmdn-00.txt

Some inline discussion:

Salvatore Loreto (JO/LMF) wrote:
> Hi ,
> 
> some comments in line
> 
> br
> /sal
> 
> On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote:
>> Hi:
>>
>> So, a summary of draft-stafford-simple-dmdn is  that there is a use case 
>> that is not covered by the current IMDN, which is:
>>
>> - An MSRP session is intercepted by a store-and-forward server. The 
>> sender would like to be informed when the final recipient receives or 
>> reads the message(s).
>>
>> One first question about the use case. It appears form the text in the 
>> draft that the use case applies only to large messages. However, I can 
>> envision store-and-forward servers that store a complete MSRP session 
>> (not only ONE large message).
> 
> you are right, if you have a store-and-forward in the path this is a
> possible scenario, even if I can not imagine at present a specific use
> case. (e.g. Why someone would establish a MSRP session with an off-line
> user and start to chat with him?)

Well, look at commercial systems. They do it. I can do it. I actually do 
it... I establish a session with some offline friend to send a few 
messages, or pending items, such as my latest pictures. This is a real 
use case.

>> I think it is important to consider these collections of MSRP messages, 
>> because, imagine we add something to the CPIM headers of each MSRP SEND 
>> requesting delivery disposition notification, then the sender will 
>> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND 
>> request. I guess this is not reasonable.
> 
> I agree. 
> A solution could be that the store-and-forward server collect all the
> message in one single big message, but in this case it shouldn't be any
> more a simple store-and-forward.

Certainly that is one possibility. Another one is to promote the IMDN 
request to the INVITE, and provide a "session-level" IMDN.

In any case, I think these should be dependent on the presence of a 
store-and-forward server in the path.

/Miguel

> 
>> On the other hand, if there isn't a store-and-forward server in the 
>> path, then there is no need for the sender to receive additional 
>> notifications, because the success reports in MSRP will do the job.
>>
>> So, I guess where we are going is to get some sort of conditional IMDN 
>> for MSRP. The condition being the unavailability of the recipient to get 
>> the messages and a store-and-forward server storing them. This will 
>> obviously apply to either large messages or short ones.
> 
> I don't have a clear view on this,
> but maybe if we introduce a indication that an MRSP session is
> established for just sending one message, this indication could help.
> 
> 
>> Any views on this?
>>
>> BR,
>>
>>       Miguel
> 

--

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.garcia <at> neonsite.net
Nokia Research Center      Helsinki, Finland
Permalink | Reply | 9 comments |
headers
Salvatore Loreto (JO/LMF | 5 Feb 2007 14:39
Picon
Favicon

Re: Comments to draft-stafford-simple-dmdn-00.txt

Hi Miguel,

see the discussion on line

br
/sal

> > On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote:
> >> Hi:
> >>
> >> So, a summary of draft-stafford-simple-dmdn is  that there is a use case 
> >> that is not covered by the current IMDN, which is:
> >>
> >> - An MSRP session is intercepted by a store-and-forward server. The 
> >> sender would like to be informed when the final recipient receives or 
> >> reads the message(s).
> >>
> >> One first question about the use case. It appears form the text in the 
> >> draft that the use case applies only to large messages. However, I can 
> >> envision store-and-forward servers that store a complete MSRP session 
> >> (not only ONE large message).
> > 
> > you are right, if you have a store-and-forward in the path this is a
> > possible scenario, even if I can not imagine at present a specific use
> > case. (e.g. Why someone would establish a MSRP session with an off-line
> > user and start to chat with him?)
> 
> 
> Well, look at commercial systems. They do it. I can do it. I actually do 
> it... I establish a session with some offline friend to send a few 
> messages, or pending items, such as my latest pictures. This is a real 
> use case.

Yes I am aware that some IM programs behave in this way.
What I don't see is the necessity to have or provide a delivery
notification in this scenario, and in fact they don't do.
But I understand and fully agree with your concern about adding some
header for Deliver Notification in the CPIM headers of each MSRP SEND
request.

> 
> 
> >> I think it is important to consider these collections of MSRP messages, 
> >> because, imagine we add something to the CPIM headers of each MSRP SEND 
> >> requesting delivery disposition notification, then the sender will 
> >> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND 
> >> request. I guess this is not reasonable.
> > 
> > I agree. 
> > A solution could be that the store-and-forward server collect all the
> > message in one single big message, but in this case it shouldn't be any
> > more a simple store-and-forward.
> 
> Certainly that is one possibility. Another one is to promote the IMDN 
> request to the INVITE, and provide a "session-level" IMDN.

yes, promoting the IMDN request to the INVITE could work in both the
scenario: the only one large message and several short/normal messages.
It can say to the final recipient to send an IMDN to the original sender
when as soon as he has received the whole large message or all the short
messages. For example as soon the store and forward server close the
MSRP session.
But promoting the IMDN request to the INVITE levels means we have also
put at this level same information about the original sender. what do
you think about?

> 
> In any case, I think these should be dependent on the presence of a 
> store-and-forward server in the path.
> 
> 
> 
> /Miguel
> 
> 
> > 
> >> On the other hand, if there isn't a store-and-forward server in the 
> >> path, then there is no need for the sender to receive additional 
> >> notifications, because the success reports in MSRP will do the job.
> >>
> >> So, I guess where we are going is to get some sort of conditional IMDN 
> >> for MSRP. The condition being the unavailability of the recipient to get 
> >> the messages and a store-and-forward server storing them. This will 
> >> obviously apply to either large messages or short ones.
> > 
> > I don't have a clear view on this,
> > but maybe if we introduce a indication that an MRSP session is
> > established for just sending one message, this indication could help.
> > 
> > 
> >> Any views on this?
> >>
> >> BR,
> >>
> >>       Miguel
> > 
>
Permalink | Reply | 8 comments |
headers
Miguel Garcia | 5 Feb 2007 14:42
Picon

Re: Comments to draft-stafford-simple-dmdn-00.txt

Salvatore Loreto (JO/LMF) wrote:

> But promoting the IMDN request to the INVITE levels means we have also
> put at this level same information about the original sender. what do
> you think about?
> 

I think it is not a straight forward option. At least, I would like to 
re-use IMDN as much as possible. Including IMDN requests in INVITE 
requests is not feasible today, since IMDN requests are embedded in CPIM 
messages, and we don't have CPIM in INVITE requests.

/Miguel
--

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.garcia <at> neonsite.net
Nokia Research Center      Helsinki, Finland
Permalink | Reply | 2 comments |

Gmane