Subject: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 4 Sep 2012 15:35:43 +0200

I am forwarding this discussion/comments with Adrian Farrel in case 
someone has an opinion different than the one I expressed.

-------- Original Message --------
Subject: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with 
DISCUSS and COMMENT)
Date: Tue, 4 Sep 2012 15:32:58 +0200
From: Miguel A. Garcia <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: The IESG <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>

Hi Adrian:

Thanks for your comments. Please find some answers inline.

On 04/09/2012 14:16, Adrian Farrel wrote:
> Adrian Farrel has entered the following ballot position for
> draft-ietf-simple-chat-16: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks, this is a well-written and easy-to-read document. Just a couple
> (well, three) of small issues that I would like to Discuss.
>
> ---
>
> Surpised that there are no requirements on authetication or control of
> admission to chat rooms. Was this topic discussed by the WG and left out
> on purpose (in which case we should add a note to that effect), was it
> forgotten (in which case we should address it), or is it not relevant
> for this type of chat (in which case you just need to explain it to me)?

This draft expands on many others, including SIP, conferences, SDP, and
MSRP. Authentication and authorization lies withing those protocols.

In particular, this draft builds on RFC 4353 (SIP Conferencing
Framework), which in Section 7 says:

     Conferences frequently require security features in order to properly
     operate.  The conference policy may dictate that only certain
     participants can join, or that certain participants can create new
     policies.  Generally speaking, conference applications are very
     concerned about authorization decisions.  Having mechanisms for
     establishing and enforcing such authorization rules is a central
     concept throughout this document.

     Of course, authorization rules require authentication.  Normal SIP
     authentication mechanisms should suffice for the conference
     authorization mechanisms described here.

>
> I would assume that the INVITE can be policed in some way. The best I
> could find was in Section 5.2
>
>     Participants usually join the chat room by sending an INVITE request
>     to the chat room URI.  As long as the chat room policy allows, the
>     INVITE request is accepted by the focus and the user is brought into
>     the actual chat room.
>
> Indeed, there are several mentions of things being allowed according to
> chat-room policy, but no wider discussion of the full set of policy
> attributes, or how chat room policy is set.

Right, perhaps the text could be improved by replacing the above
paragraph with this one:

Participants usually join the chat room by sending an INVITE request to
the chat room URI. The chat room them uses regular SIP mechanisms to
authenticate the participant. This may include, e.g., client
certificates, SIP Digest authentication [RFC3261], asserted network
identity [RFC3325], etc. As long as the user is authenticated, the INVITE
request is accepted by the focus and the user is brought into
the actual chat room.

Now, about the policy of the chat room. I think you have a good point.
There should be a single place where we can list all the policy
attributes and their semantics. Currently these are spread throughout the
document, making it difficult to keep track of them.

To address this issue, I suggest to add a new section 4.1, (inside the
Overview of Operation), that briefly lists all those policy attributes
and refers to sections where they are described in the appropriate context.

>
> ---
>
> Section 6.1
>
>     On sending a regular message the sender MUST populate the To header
>     of the Message/CPIM wrapper with the URI of the chat room.  The
>     sender SHOULD populate the From header of the Message/CPIM wrapper
>     with a proper identifier by which the user is recognized in the chat
>     room.
>
> I'm uncomfortable with the "SHOULD" here. It implies that you can think
> of a good reason why the sender MAY use some other (improper) identifier
> or no identifier at all. Can you either give an example (perhaps: "The
> sender MAY set an arbitrary and meaningless value in order to hide its
> identitiy"), or tighten the SHOULD to a MUST.

Honestly, I don't remember any scenario where a participant could
populate the From header of the Message/CPIM wrapper with some other
identifier. Even if the user is using an Anonymous URI at the SIP level,
he should use the same URI in Message/CPIM, in which case the MUST is
still valid.

I proposed to replace the SHOULD with a MUST.

>
> ---
>
> Section 6.1
>
>     An MSRP
>     switch that uses this fast forwarding procedure MUST temporarily
>     store the Message-Id of the MSRP message to correlate the different
>     chunks, as well as it MUST temporarily store the list of recipients
>     to which the initial chunks were delivered.
>
> The motivaiton is clear. I think you could add that the storage can be
> released when the last chunk is seen. But what happens when the last
> chunk is not seen (or delayed)? How temporary is the storage, and how is
> it released?

Yes, we can add that the temporary storage is released when the last
chunk is seen or after a reasonable time passes.
>
> Or do we assume that because MSRP uses TCP (or similar) that loss will
> always be accompanied by connection failure and so that is the only
> trigger needed to abandon temporary storage?

Yes, on one side, the assumption is that if a last chunk is not seen is
because there has been a transport failure. Since TCP is used, then the
TCP connection was broken, and is in the process of being re-established.
I am more concerned about what happens if the last chunk is not seen at
all, I am not sure the state the MSRP session will be, even if the
connection is re-established.

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 4
>
>     In order to enter a chat room, one must first be created.
>
> Obviously, I spend to much time hanging out with the Queen, but when you
> say "one must be created" I suspect you meant the chat room, not one's
> self. Maybe reword as...
>
> Before a chat room can be entered, it must be created.
>

Ok.

> ---
>
> Section 6.1 (trivial nit)
>
>     The SEND request MUST contain a top-level wrapper of type 'Message/
>     CPIM' according to RFC 3862 [RFC3862].  The actual instant message
>     payload MUST be included as payload of the 'Message/CPIM' wrapper and
>     MAY be of any type negotiated in the SDP 'accept-types' attribute
>     according to the MSRP rules.
>
> I think s/MAY/may/. That is, a type must be set, and the type must be
> only one of those that has been negotiated.
>
>

I think this MAY should actually be a MUST, because as you said, a types
must be said, and this type cannot be anyone, but it MUST be one of those
negotiated.

I like the "according to the MSRP rules", as a mechanism to indicate that
we are not mandating something new, but just copying what MSRP mandates.

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Ben Campbell <[email-masked]>
Date: Tue, 4 Sep 2012 09:12:16 -0500

(As Chair)

Everyone please note that Miguel's response involves some teaks to normative language. They are small, but still substantive. This email will serve to    vet any such changes with the working group--if you have any objection, please say so ASAP.

Thanks!

Ben.

On Sep 4, 2012, at 8:35 AM, "Miguel A. Garcia" <[email-masked]> wrote:

> I am forwarding this discussion/comments with Adrian Farrel in case someone has an opinion different than the one I expressed.
> 
> 
> Subject: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)
> CC: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> Hi Adrian:
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Tue, 4 Sep 2012 09:26:14 -0500

(As individual)

Hi,

I agree with Miguel's responses except as noted inline

Thanks!

Ben.

> chunk is seen or after a reasonable time passes.

The "how long to wait for a chunk" problem is no different than for any other endpoint, is it, other than possibly differences of scale? I suggest we refer back to 4975 for this, with the possible note to the effect of "This is no different than for any MSRP endpoint that receives a chunked message. However, since a conference switch will typically participate many sessions at one time, storage management may be more critical"

> connection is re-established.

Keep in mind there could be an MSRP relay between the sender and the switch, so the transport connection may not be direct. But again, this is no different than for any other MSRP endpoint.

> must be said, and this type cannot be anyone, but it MUST be one of those

This is already mandated in RFC4975 (as you go on to say...). The only thing new is the normative requirement for a particular wrapper type. It might be worth commenting that this is accomplished by putting only Message/CPIM in accept-types, and all allowed leaf types in accept-wrapped-types.

> we are not mandating something new, but just copying what MSRP mandates.

... in which case it should be stated descriptively, not normatively.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Sep 2012 11:29:49 -0400

> connection is re-established.

Because a failed TCP connection may be reestablished, and the chunk sent 
over the new connection, you can't use connection loss as a trigger for 
giving up on incomplete chunked messages.

The receiver has no firm way to distinguish between a chunk that has 
been a chunk that has been lost and one that has simply been delayed. 
This has to be dealt with via implementation policies and heuristics.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 4 Sep 2012 11:07:36 -0500

On Sep 4, 2012, at 10:29 AM, Paul Kyzivat <[email-masked]> wrote:

> Because a failed TCP connection may be reestablished, and the chunk sent over the new connection, you can't use connection loss as a trigger for giving up on incomplete chunked messages.
> 
> The receiver has no firm way to distinguish between a chunk that has been a chunk that has been lost and one that has simply been delayed. This has to be dealt with via implementation policies and heuristics.

That's a good point. While a connection failure ends the "session", the endpoints can attempt to reestablish a new session and send the remaining chunks over it. So I concur the best we can offer is to wait a "reasonable time". I can see "reasonable" being different for a high-volume switch than for an end-user endpoint.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 5 Sep 2012 09:15:48 +0200

Hi Ben,

Thanks for your comments

On 04/09/2012 16:26, Ben Campbell wrote:
>>> An MSRP switch that uses this fast forwarding procedure MUST
>>> temporarily store the Message-Id of the MSRP message to correlate
>>> the different chunks, as well as it MUST temporarily store the
>>> list of recipients to which the initial chunks were delivered.
>>>
>>> The motivaiton is clear. I think you could add that the storage
>>> can be released when the last chunk is seen. But what happens when
>>> the last chunk is not seen (or delayed)? How temporary is the
>>> storage, and how is it released?
>>
>> Yes, we can add that the temporary storage is released when the
>> last chunk is seen or after a reasonable time passes.
>
> The "how long to wait for a chunk" problem is no different than for
> any other endpoint, is it, other than possibly differences of scale? I
> suggest we refer back to 4975 for this, with the possible note to the
> effect of "This is no different than for any MSRP endpoint that
> receives a chunked message. However, since a conference switch will
> typically participate many sessions at one time, storage management
> may be more critical"

I would like to include a reference to the section in RFC 4975 that 
discusses this topic. I guess it is Section 5.3, when it discusses what 
happens if a transport connection fails.

>
>>>
>>> Or do we assume that because MSRP uses TCP (or similar) that loss
>>> will always be accompanied by connection failure and so that is
>>> the only trigger needed to abandon temporary storage?
>>
>> Yes, on one side, the assumption is that if a last chunk is not seen
>> is because there has been a transport failure. Since TCP is used,
>> then the TCP connection was broken, and is in the process of being
>> re-established. I am more concerned about what happens if the last
>> chunk is not seen at all, I am not sure the state the MSRP session
>> will be, even if the connection is re-established.
>
> Keep in mind there could be an MSRP relay between the sender and the
> switch, so the transport connection may not be direct. But again, this
> is no different than for any other MSRP endpoint.

Exactly. Here we clearly need to refer to Section 5.3 of RFC 4975.

>>> The SEND request MUST contain a top-level wrapper of type
>>> 'Message/ CPIM' according to RFC 3862 [RFC3862].  The actual
>>> instant message payload MUST be included as payload of the
>>> 'Message/CPIM' wrapper and MAY be of any type negotiated in the
>>> SDP 'accept-types' attribute according to the MSRP rules.
>>>
>>> I think s/MAY/may/. That is, a type must be set, and the type must
>>> be only one of those that has been negotiated.
>>>
>>>
>>
>> I think this MAY should actually be a MUST, because as you said, a
>> types must be said, and this type cannot be anyone, but it MUST be
>> one of those negotiated.
>
> This is already mandated in RFC4975 (as you go on to say...). The only
> thing new is the normative requirement for a particular wrapper type.
> It might be worth commenting that this is accomplished by putting only
> Message/CPIM in accept-types, and all allowed leaf types in
> accept-wrapped-types.

Ok, we can clarify it. Actually, we do not mention what can go in an 
accept-wrapped-types, because it was obvious that any type can go in. But 
it might be worth adding some explicit mention to it.

>
>>
>> I like the "according to the MSRP rules", as a mechanism to indicate
>> that we are not mandating something new, but just copying what MSRP
>> mandates.
>>
>

Hmmm, that is true. I suggest to move away from MUST/MAY/must/may. I 
think the text ought to say: "According to RFC 4975, the endpoint needs 
to  ...". This is makes it clear, and we do not over-specify.

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 5 Sep 2012 09:19:18 +0200

In my previous e-mail, please s/5.3/5.4

To be explicit: the MSRP Connection Model is described in Section 5.4 of 
RFC 4975.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 5 Sep 2012 09:30:22 +0200

Thank you Paul,

I think you are right, under failure circumstances chunks might be sent 
over different MSRP sessions, if a new session is re-established.

So, I believe the only mechanism we have for a permanent deletion of a 
partially received message is set a timer.

In a chat room environment, this means that when this type of failure 
occurs, the MSRP switch might have sent a number of chunks to the rest of 
the participants, leaving the total message incomplete at those 
endpoints. I wonder if the MSRP switch should, in this case, create an 
abort chunk ("#" flag) to avoid that the rest of the endpoints remain in 
a strange state. I think so.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 5 Sep 2012 15:32:53 +0200

In relation with the issue of chunked messages, where the MSRP switch 
does not receive a last chunk due to, e.g., the sender's connection is 
dropped, I have a proposal and a doubt.

Proposal:

	  Once the MSRP switch receives the last chunk of a message,
	  and that chunk is successfully sent to each of the
	  recipients, the MSRP switch MUST discard the temporary
	  storage of MSRP Message-ID and the associated list of
	  recipients.

	  In some occasions, a sender might suffer a transport error
	  condition (such as loss of connectivity) that makes the
	  sending of a message incomplete, e.g., some chunks were
	  received by the MSRP switch, but not all of them. This is a
	  behavior already considered in the core MSRP specification
	  (see <xref target="RFC4575"> RFC 4575 </xref> Section
	  5.4). The problem in the context of a chat room lies with
	  the usage of temporary storage for fast forwarding. In order
	  to prevent attacks related to the exhaustion of temporary
	  storage of chunked messages, on receiving a first chunk of a
	  message, where the MSRP switch is using the fast forward
	  method, the MSRP switch MUST set a timer for controlling the
	  reception of the remaining chunks. This timer can be re-set
	  every time a new chunk of the same message is received. When
	  this timer fires, the MSRP switch MUST considered that the
	  sending of the message was aborted, and MUST delete all the
	  temporary storage pertaining to this message.

Now the doubt. If the above condition happens, I would like to know what 
is best to do with respect the recipients. These are in a strange state, 
where they have received a number of chunks of a message, but not all the 
chunks, and they will not receive any more. What the MSRP switch can do:

a) Nothing. The recipients have received a number of a chunks of a 
message; the message is not complete. The MSRP switch will send other 
messages (perhaps originated by other participants), but this chunked 
message will remain in the endpoints until the endpoint 
crashes^H^H^H^H^H^H^Hrecovers from that situation.

b) A nice MSRP switch will create a new chunk, as it if were received 
from the sender, where there won't be any content, but just the abort 
flag "#". At least this one will have a bigger likelihood of endpoint 
recovery.

I propose to do b). I guess there are no security issues, even if TLS is 
used, because the TLS connection is ending at the MSRP switch.

Can anyone think of other options? Is option b) reasonable?

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Sep 2012 08:49:14 -0500

On Sep 5, 2012, at 2:30 AM, "Miguel A. Garcia" <[email-masked]> wrote:

> Thank you Paul,
> 
> I think you are right, under failure circumstances chunks might be sent over different MSRP sessions, if a new session is re-established.
> 
> So, I believe the only mechanism we have for a permanent deletion of a partially received message is set a timer.
> 
> In a chat room environment, this means that when this type of failure occurs, the MSRP switch might have sent a number of chunks to the rest of the participants, leaving the total message incomplete at those endpoints. I wonder if the MSRP switch should, in this case, create an abort chunk ("#" flag) to avoid that the rest of the endpoints remain in a strange state. I think so.

I agree.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 5 Sep 2012 16:35:46 +0200

I am now addressing the issue with accept-types and accept-wrapped-types.

There are two affected sections:

Section 5.2 discusses the SDP offer/answer when joining a chat room. The 
text now reads:

           The conference focus of a chat room MUST include support for
           a <xref target="RFC3862">Message/CPIM</xref> top-level
           wrapper for the MSRP messages by setting the 'accept-types'
           MSRP media line attribute in the <xref target="RFC3264">SDP
           offer or answer </xref> to include 'Message/CPIM'. The
           actual payload type is negotiated in the
           'accept-wrapped-types' attribute in SDP (see <xref
           target="RFC4575">RFC 4575 </xref> for details). There is no
           default wrapped type. Typical wrapped type values can
           include: text/plain, text/html, image/jpeg, image/png,
           audio/mp3, etc.

The other paragraph is in Section 6.1 (Regular messages), when we want to 
say that the MSRP SEND request needs to use one of the payloads 
negotiated in the accept-wrapped-types:

	  The SEND request MUST contain a top-level wrapper of type
	  'Message/CPIM' according to <xref target="RFC3862">RFC
	  3862</xref>. The actual instant message payload MUST be
	  included as payload of the 'Message/CPIM' wrapper, and,
	  according to <xref target="RFC4575"> RFC 4575</xref>, it
	  needs to be one of those negotiated in the
	  'accept-wrapped-types' attribute in SDP.

Please note that in this last paragraph there is a bug in the current 
version of the draft. The last sentence incorrectly pointed to the 
'accept-types' attribute, rather than the 'accept-wrapped-types'. I 
believe the proposed text above is now correct.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Sep 2012 10:43:58 -0400

>> In a chat room environment, this means that when this type of failure occurs, the MSRP switch might have sent a number of chunks to the rest of the participants, leaving the total message incomple…

Will the MSRP switch necessarily *know* that this failure has occurred?

The switch is not obligated to receive the complete message before 
forwarding. It needs to remember incomplete messages, but need not 
consume buffer space for them. So it may tolerate an incomplete message 
for a long time.

*If* it decides to give up on a message with a missing chunk then I 
agree that it makes sense for it to tell the downstream recipients as 
suggested. But they had better not *depend* on this.

	Thanks,
	Paul

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 5 Sep 2012 16:46:47 +0200

Hi,

On Sep 5, 2012, at 3:32 PM, Miguel A. Garcia wrote:

> In relation with the issue of chunked messages, where the MSRP switch does not receive a last chunk due to, e.g., the sender's connection is dropped, I have a proposal and a doubt.
> 
> Proposal:
> 

"the MSRP switch MUST consider that the"

> Now the doubt. If the above condition happens, I would like to know what is best to do with respect the recipients. These are in a strange state, where they have received a number of chunks of a message, but not all the chunks, and they will not receive any more. What the MSRP switch can do:
> 
> a) Nothing. The recipients have received a number of a chunks of a message; the message is not complete. The MSRP switch will send other messages (perhaps originated by other participants), but this chunked message will remain in the endpoints until the endpoint crashes^H^H^H^H^H^H^Hrecovers from that situation.
> 
> b) A nice MSRP switch will create a new chunk, as it if were received from the sender, where there won't be any content, but just the abort flag "#". At least this one will have a bigger likelihood of endpoint recovery.
> 
> I propose to do b). I guess there are no security issues, even if TLS is used, because the TLS connection is ending at the MSRP switch.
> 

I agree with taking the b option approach, it's reasonable.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Sep 2012 10:51:50 -0400

I just went back and checked the draft text again, and conclude that my 
comment didn't make much sense. I was thinking the concern was with 
message buffer space. I see now that it was only concerned with 
buffering the message id and list of recipients. This is likely to be a 
low burden, so the server might be willing to buffer a lot of this sort 
of state. But it will still eventually need to give up on it. And the 
proposal is valid when it does give up.

	Thanks,
	Paul

On 9/5/12 10:43 AM, Paul Kyzivat wrote:
>>> I think you are right, under failure circumstances chunks might be
>>> sent over different MSRP sessions, if a new session is re-established.
>>>
>>> So, I believe the only mechanism we have for a permanent deletion of
>>> a partially received message is set a timer.
>>>
>>> occurs, the MSRP switch might have sent a number of chunks to the
>>> rest of the participants, leaving the total message incomplete at
>>> those endpoints. I wonder if the MSRP switch should, in this case,
>>> create an abort chunk ("#" flag) to avoid that the rest of the
>>> endpoints remain in a strange state. I think so.
>>
>> I agree.
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Sep 2012 11:10:26 -0500

On Sep 5, 2012, at 9:43 AM, Paul Kyzivat <[email-masked]> wrote:

> The switch is not obligated to receive the complete message before forwarding. It needs to remember incomplete messages, but need not consume buffer space for them. So it may tolerate an incomplete message for a long time.
> 
> *If* it decides to give up on a message with a missing chunk then I agree that it makes sense for it to tell the downstream recipients as suggested. But they had better not *depend* on this.

Agreed. The final recipients must be able to deal with missing chunks, regardless of what the switch does. On reflection, it doesn't seem like the switch has to keep all that much state if it's doing fast forwarding, i.e. it doesn't to store chunks for reassembly like the final recipient does. So I'd almost see this is a "MAY discard the message-id after some reasonable period of time, based on local policy."

I first thought we needed the abort chunk--but it's really just an optimization. I wonder if it's worth it to introduce a need to originate content. Are there situations where it could do harm? S/MIME signed content might be one, but I guess if all the chunks don't make it, the signature is toast anyway.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Sep 2012 11:12:17 -0500

On Sep 5, 2012, at 9:51 AM, Paul Kyzivat <[email-masked]> wrote:

> I just went back and checked the draft text again, and conclude that my comment didn't make much sense. I was thinking the concern was with message buffer space. I see now that it was only concerned with buffering the message id and list of recipients. This is likely to be a low burden, so the server might be willing to buffer a lot of this sort of state. But it will still eventually need to give up on it. And the proposal is valid when it does give up.
> 

I agree with the comment you just withdrew :-)

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Sep 2012 13:54:10 -0500

On Sep 5, 2012, at 8:32 AM, Miguel A. Garcia <[email-masked]> wrote:

> 	  received by the MSRP switch, but not all of them.

It's not limited to transport failures. For example, the sender could lose power before completing the message.

> This is a
> 	  the usage of temporary storage for fast forwarding.

Seems like it would be even worse if you weren't doing fast forwarding. Then the switch would be saving the chunk contents for reassembly, wouldn't it?

> In order

Repeating a comment from a separate thread:

On reflection, I'm not sure we need to be aggressive with the normative language here. The receiving endpoints already have to be able to deal with missing chunks. We are talking about optimizations here, not interop-critical behavior. I would lean towards making it clear that a switch doesn't have to keep the message-id and recipients around forever, and allow it to send a cancelation chunk if it wants to, but not require it. Specifically, something to the effect of the following:

1) The switch MAY discard the message state if it receives no chunks within some reasonable time. The specific timeout value is a matter of local policy, but SHOULD NOT be too short. For example, a time interval on the order of a normal TCP timeout (i.e. around 9 minutes)  would be reasonable. A timeout on the order of a few seconds would not.

2) If a timeout occurs, or some other error occurs that prevents all chunks from arriving at the switch, the switch MAY choose to send a cancelation chunk. This is an optimization, since MSRP endpoints need to be able to handle incomplete messages anyway.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Sep 2012 14:05:26 -0500

On Sep 5, 2012, at 9:35 AM, Miguel A. Garcia <[email-masked]> wrote:

> Section 5.2 discusses the SDP offer/answer when joining a chat room. The text now reads:
> 
>          offer or answer </xref> to include 'Message/CPIM'.

_only_ Message/CPIM, right? Or can other media types be included at the root?

> The

Assuming you mean 4975, it looks good. We could mention the use of "*", but I think that's already covered by the reference, and we don't want to restate too much here.

> 
> 
> The other paragraph is in Section 6.1 (Regular messages), when we want to say that the MSRP SEND request needs to use one of the payloads negotiated in the accept-wrapped-types:
> 
> Please note that in this last paragraph there is a bug in the current version of the draft. The last sentence incorrectly pointed to the 'accept-types' attribute, rather than the 'accept-wrapped-types'. I believe the proposed text above is now correct.

Looks good, again assuming you mean 4975.

---

From: Adam Roach <[email-masked]>
Date: Wed, 05 Sep 2012 14:09:32 -0500

> 2) If a timeout occurs, or some other error occurs that prevents all chunks from arriving at the switch, the switch MAY choose to send a cancelation chunk. This is an optimization, since MSRP endpo…

I agree with this suggestion.

I think making #2 optional makes sense, since it alleviates any of 
Miguel's concerns that sending the cancellation chunk might constitute 
an undue burden on the switch, while leaving open the ability of the 
switch to indicate that no further chunks will be arriving in a message.

I also think leaving the exact implementation details of #1 at the 
discretion of the switch makes sense. For example -- it might be 
perfectly fine for the switch to keep the state around for as long as 
the session exists, possibly removing state bindings on a LRU-basis (so 
as to avoid excessive state utilization). For some architectures, this 
might make more sense than running strict timers.

I also like the suggestion that any such state needs to stay around for 
at least as long as TCP retransmits information. It guarantees that the 
relay won't needlessly prevent delivery of a message by giving the 
underlying transport time to do everything it can.

/a

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 6 Sep 2012 12:22:47 +0200

A couple of comments below.

On 05/09/2012 18:10, Ben Campbell wrote:
>>>> I think you are right, under failure circumstances chunks might
>>>> be sent over different MSRP sessions, if a new session is
>>>> re-established.
>>>>
>>>> So, I believe the only mechanism we have for a permanent
>>>> deletion of a partially received message is set a timer.
>>>>
>>>> In a chat room environment, this means that when this type of
>>>> failure occurs, the MSRP switch might have sent a number of
>>>> chunks to the rest of the participants, leaving the total
>>>> message incomplete at those endpoints. I wonder if the MSRP
>>>> switch should, in this case, create an abort chunk ("#" flag) to
>>>> avoid that the rest of the endpoints remain in a strange state.
>>>> I think so.
>>>
>>> I agree.
>>

The only way for the MSRP switch to detect this failure is through a timer.

>> consume buffer space for them. So it may tolerate an incomplete
>> message for a long time.
>>
>> agree that it makes sense for it to tell the downstream recipients
>> as suggested. But they had better not *depend* on this.
>
> Agreed. The final recipients must be able to deal with missing chunks,
> regardless of what the switch does.

The final recipients should be already be able to deal with missing 
chunks with regular MSRP (outside the chat context). An endpoint might be 
receiving MSRP chunks through a relay. The sender's connection with the 
relay goes down; the recipient should be able to deal with this case.

> On reflection, it doesn't seem
> like the switch has to keep all that much state if it's doing fast
> forwarding, i.e. it doesn't to store chunks for reassembly like the
> final recipient does. So I'd almost see this is a "MAY discard the
> message-id after some reasonable period of time, based on local
> policy."

Sounds reasonable.

>
> I first thought we needed the abort chunk--but it's really just an
> optimization. I wonder if it's worth it to introduce a need to
> originate content. Are there situations where it could do harm? S/MIME
> signed content might be one, but I guess if all the chunks don't make
> it, the signature is toast anyway.

Yeah, provoking an abort seems to be an optimization that the MSRP switch 
will do to the endpoints. Somehow I am leaning towards adding a "MAY" 
send an abort if this condition is detected.

/Miguel

>> Thanks, Paul
>>>>> Because a failed TCP connection may be reestablished, and the
>>>>> chunk sent over the new connection, you can't use connection
>>>>> loss as a trigger for giving up on incomplete chunked
>>>>> messages.
>>>>>
>>>>> The receiver has no firm way to distinguish between a chunk
>>>>> that has been a chunk that has been lost and one that has
>>>>> simply been delayed. This has to be dealt with via
>>>>> implementation policies and heuristics.
>>>>>
>>>>
>>>> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
>>>
>>>
>>
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 6 Sep 2012 12:27:52 +0200

Thank you Saúl.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 6 Sep 2012 12:45:24 +0200

Hi Ben:

Some inline comments.

On 05/09/2012 20:54, Ben Campbell wrote:
>> In relation with the issue of chunked messages, where the MSRP
>> switch does not receive a last chunk due to, e.g., the sender's
>> connection is dropped, I have a proposal and a doubt.
>>
>> Proposal:
>>
>> Once the MSRP switch receives the last chunk of a message, and that
>> chunk is successfully sent to each of the recipients, the MSRP
>> switch MUST discard the temporary storage of MSRP Message-ID and the
>> associated list of recipients.
>>
>>
>> In some occasions, a sender might suffer a transport error condition
>> (such as loss of connectivity) that makes the sending of a message
>> incomplete, e.g., some chunks were received by the MSRP switch, but
>> not all of them.
>
> It's not limited to transport failures. For example, the sender could
> lose power before completing the message.

True, that is another example of loss of connectivity. I will add it.

>
>> This is a behavior already considered in the core MSRP
>> specification (see <xref target="RFC4575"> RFC 4575 </xref> Section
>> 5.4). The problem in the context of a chat room lies with the usage
>> of temporary storage for fast forwarding.
>
> Seems like it would be even worse if you weren't doing fast
> forwarding. Then the switch would be saving the chunk contents for
> reassembly, wouldn't it?

Yeah, you hit a point that I was thinking yesterday when I was composing
the text. The need of a timer to detect incomplete messages (due to chunk
messaging) is not restricted to the fast forwarding mechanism, but it is
also applicable when the non-fast forwarding mechanism is used.

Let's keep this in mind. First I want to get the text correct and
complete focusing on the fast forwarding mechanism. Then we will need to
extrapolate it to the non-fast forwarding mechanism.

>
>> In order to prevent attacks related to the exhaustion of temporary
>> message, where the MSRP switch is using the fast forward method, the
>> MSRP switch MUST set a timer for controlling the reception of the
>> remaining chunks. This timer can be re-set every time a new chunk of
>> the same message is received. When this timer fires, the MSRP switch
>> MUST considered that the sending of the message was aborted, and
>> MUST delete all the temporary storage pertaining to this message.
>>
>> Now the doubt. If the above condition happens, I would like to know
>> what is best to do with respect the recipients. These are in a
>> strange state, where they have received a number of chunks of a
>> message, but not all the chunks, and they will not receive any more.
>> What the MSRP switch can do:
>>
>> message; the message is not complete. The MSRP switch will send
>> other messages (perhaps originated by other participants), but this
>> chunked message will remain in the endpoints until the endpoint
>> b) A nice MSRP switch will create a new chunk, as it if were
>> received from the sender, where there won't be any content, but just
>> the abort flag "#". At least this one will have a bigger likelihood
>> of endpoint recovery.
>>
>> I propose to do b). I guess there are no security issues, even if
>> TLS is used, because the TLS connection is ending at the MSRP
>> switch.
>>
> On reflection, I'm not sure we need to be aggressive with the
> normative language here. The receiving endpoints already have to be
> able to deal with missing chunks. We are talking about optimizations
> here, not interop-critical behavior. I would lean towards making it
> clear that a switch doesn't have to keep the message-id and recipients
> around forever, and allow it to send a cancelation chunk if it wants
> to, but not require it. Specifically, something to the effect of the
> following:
>
> 1) The switch MAY discard the message state if it receives no chunks
> within some reasonable time. The specific timeout value is a matter of
> local policy, but SHOULD NOT be too short. For example, a time
> interval on the order of a normal TCP timeout (i.e. around 9 minutes)
> would be reasonable. A timeout on the order of a few seconds would
> not.
>
> 2) If a timeout occurs, or some other error occurs that prevents all
> chunks from arriving at the switch, the switch MAY choose to send a
> cancelation chunk. This is an optimization, since MSRP endpoints need
> to be able to handle incomplete messages anyway.

Totally agreed. I will work to reflect this in the draft.

/Miguel

>>> To be explicit: the MSRP Connection Model is described in Section
>>> 5.4 of RFC 4975.
>>>
>>> /Miguel
>>>
>>>>>>> An MSRP switch that uses this fast forwarding procedure
>>>>>>> MUST temporarily store the Message-Id of the MSRP message
>>>>>>> to correlate the different chunks, as well as it MUST
>>>>>>> temporarily store the list of recipients to which the
>>>>>>> initial chunks were delivered.
>>>>>>>
>>>>>>> The motivaiton is clear. I think you could add that the
>>>>>>> storage can be released when the last chunk is seen. But
>>>>>>> what happens when the last chunk is not seen (or delayed)?
>>>>>>> How temporary is the storage, and how is it released?
>>>>>>
>>>>>> Yes, we can add that the temporary storage is released when
>>>>>> the last chunk is seen or after a reasonable time passes.
>>>>>
>>>>> The "how long to wait for a chunk" problem is no different
>>>>> than for any other endpoint, is it, other than possibly
>>>>> differences of scale? I suggest we refer back to 4975 for
>>>>> this, with the possible note to the effect of "This is no
>>>>> different than for any MSRP endpoint that receives a chunked
>>>>> message. However, since a conference switch will typically
>>>>> participate many sessions at one time, storage management may
>>>>> be more critical"
>>>>
>>>>
>>>> I would like to include a reference to the section in RFC 4975
>>>> that discusses this topic. I guess it is Section 5.3, when it
>>>> discusses what happens if a transport connection fails.
>>>>
>>>>>
>>>>>>>
>>>>>>> Or do we assume that because MSRP uses TCP (or similar)
>>>>>>> that loss will always be accompanied by connection failure
>>>>>>> and so that is the only trigger needed to abandon
>>>>>>> temporary storage?
>>>>>>
>>>>>> Yes, on one side, the assumption is that if a last chunk is
>>>>>> not seen is because there has been a transport failure.
>>>>>> Since TCP is used, then the TCP connection was broken, and
>>>>>> is in the process of being re-established. I am more
>>>>>> concerned about what happens if the last chunk is not seen
>>>>>> at all, I am not sure the state the MSRP session will be,
>>>>>> even if the connection is re-established.
>>>>>
>>>>> Keep in mind there could be an MSRP relay between the sender
>>>>> and the switch, so the transport connection may not be direct.
>>>>> But again, this is no different than for any other MSRP
>>>>> endpoint.
>>>>
>>>>>>> 'Message/ CPIM' according to RFC 3862 [RFC3862].  The
>>>>>>> actual instant message payload MUST be included as payload
>>>>>>> of the 'Message/CPIM' wrapper and MAY be of any type
>>>>>>> negotiated in the SDP 'accept-types' attribute according
>>>>>>> to the MSRP rules.
>>>>>>>
>>>>>>> I think s/MAY/may/. That is, a type must be set, and the
>>>>>>> type must be only one of those that has been negotiated.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I think this MAY should actually be a MUST, because as you
>>>>>> said, a types must be said, and this type cannot be anyone,
>>>>>> but it MUST be one of those negotiated.
>>>>>
>>>>> This is already mandated in RFC4975 (as you go on to say...).
>>>>> The only thing new is the normative requirement for a
>>>>> particular wrapper type. It might be worth commenting that
>>>>> this is accomplished by putting only Message/CPIM in
>>>>> accept-types, and all allowed leaf types in
>>>>> accept-wrapped-types.
>>>>
>>>> Ok, we can clarify it. Actually, we do not mention what can go
>>>> in an accept-wrapped-types, because it was obvious that any type
>>>> can go in. But it might be worth adding some explicit mention to
>>>> it.
>>>>
>>>>>
>>>>>>
>>>>>> I like the "according to the MSRP rules", as a mechanism to
>>>>>> indicate that we are not mandating something new, but just
>>>>>> copying what MSRP mandates.
>>>>>>
>>>>>
>>>> Hmmm, that is true. I suggest to move away from
>>>> MUST/MAY/must/may. I think the text ought to say: "According to
>>>> RFC 4975, the endpoint needs to  ...". This is makes it clear,
>>>> and we do not over-specify.
>>>>
>>>> /Miguel
>>>>
>>>
>>
>> _______________________________________________ Simple mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/simple
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 6 Sep 2012 14:28:45 +0200

Hi Ben,

Inline comments.

> _only_ Message/CPIM, right? Or can other media types be included at the root?

Well, I expect the UA to be common to chat (through chat server) and 
point-to-point instant messaging. If this is the case, the UA will add 
the accept-types including types that are supported and useful for both 
chat and point-to-point IM. Then the MSRP switch will response with only 
Message/CPIM.

So, to summarize, the UA populatse the accept-types with all the formats 
that it supports, including Message/CPIM; the server will reply with 
Message/CPIM. The text to support this reads:

    The conference focus of a chat room MUST include support for a
    Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by
    setting the 'accept-types' MSRP media line attribute in the SDP offer
    or answer [RFC3264] to include 'Message/CPIM'.

> Looks good, again assuming you mean 4975.

Ouch. Fixed now, yes 4975. I am fixing other similar errors.

Thanks,

      Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 Sep 2012 15:12:09 -0500

On Sep 6, 2012, at 7:28 AM, Miguel A. Garcia <[email-masked]> wrote:

> Well, I expect the UA to be common to chat (through chat server) and point-to-point instant messaging. If this is the case, the UA will add the accept-types including types that are supported and useful for both chat and point-to-point IM. Then the MSRP switch will response with only Message/CPIM.

But the text talks about the what the conference focus sends, not UAs in _general_. If the focus includes anything _other_ than Message/CPIM in accept-types, it better be prepared to receive it. Is that the intent?

> 
> So, to summarize, the UA populatse the accept-types with all the formats that it supports, including Message/CPIM; the server will reply with Message/CPIM. The text to support this reads:
>

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 7 Sep 2012 10:41:56 +0200

On 06/09/2012 22:12, Ben Campbell wrote:
> But the text talks about the what the conference focus sends, not UAs in_general_. If the focus includes anything_other_  than Message/CPIM in accept-types, it better be prepared to receive it. Is that the intent?

Ben, I see your point. The conference focus MUST only send an 
accept-types of Message/CPIM. There is no reason for using any other value.

I will revise this text to make clear the intention.

BR,

      Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 10 Sep 2012 15:20:37 +0200

Ben, and the SIMPLE WG:

To clarify the usage of accept-types, I propose two paragraphs to Section 
5.2 (Joining a chat room). The first paragraph is new and discusses the 
participant's SDP. Here, I propose not to add normative text mandating 
the UA to add 'a=accept-types:Message/CPIM' in SDP. The reason is that 
such normative text would require a mechanism for the UA to know in 
advance that it is joining a chat room, perhaps by examining the chat 
room URI. But in general, such mechanism does not exist. The UA will 
create an INVITE request with SDP, not knowing if at the other end there 
is a chat room or a regular user. If this SDP contains 'm=message', the 
attributes included afterwards will be the same, no matter whether the 
participant is joining a chat room or just another endpoint. Please 
verify that the proposed words are acceptable: "...needs to include at 
least...

    This participant's INVITE request contains an SDP body.  This SDP
    body includes the description of MSRP 'message' media line as per RFC
    4975 procedures [RFC4975].  This specification requires all instant
    messages to be wrapped in a Message/CPIM wrapper [RFC3862],
    therefore, the 'accept-types' attribute for the MSRP message media in
    the participant's SDP offer needs to include at least the value
    'Message/CPIM', otherwise the conference focus will reject the
    request.  The actual instant message payload type is negotiated in
    the 'accept-wrapped-types' attribute in SDP (see RFC 4975 [RFC4975]
    for details).  There is no default wrapped type.  Typical wrapped
    type values can include: text/plain, text/html, image/jpeg, image/
    png, audio/mp3, etc.  It is RECOMMENDED that participant endpoints
    add an 'accept-wrapped-types' attribute to the MSRP 'message' media
    line in SDP, where the supported wrapped types are declared, as per
    RFC 4975 procedures [RFC4975].

Now, the second paragraph was already present in the previous version, 
and is now divided into two paragraphs. It tackles the conference focus. 
I have added text to indicate that the focus must only accept 
Message/CPIM, and also that the focus should add an 
'accept-wrapped-types'. The text reads:

    The conference focus of a chat room MUST only use a Message/CPIM
    [RFC3862] top-level wrapper as a payload of MSRP messages, and this
    needs to be declared in the SDP offer and answer as per regular RFC
    4975 procedures [RFC4975].  This implies that if the conference focus
    receives from a participant's endpoint an SDP offer that does not
    include the value 'Message/CPIM' in the 'accept-types' attribute for
    the MSRP message media line, the conference focus SHOULD either
    reject the MSRP message media stream or the complete SDP offer by
    using regular SIP or SDP procedures (e.g., creating an SDP answer
    that sets to zero the port of the MSRP message media line, responding
    the INVITE with a 488 response, etc.).

    If the conference focus accepts the participant's SDP offer, when the
    conference focus generates the SDP answer, it MUST set the 'accept-
    types' attribute for the MSRP message media line to a value of
    'Message/CPIM'.  This specification requires all instant messages to
    be wrapped in a Message/CPIM wrapper, therefore, the 'accept-types'
    attribute in this SDP body contains a single value of 'Message/CPIM'.
    The actual instant message payload type is negotiated in the 'accept-
    wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] for details).
    The conference focus SHOULD also add an 'accept-wrapped-types'
    attribute to the MSRP message media line in SDP containing the
    supported wrapped types.

Please indicate if there are problems with the proposed text.

/Miguel

On 07/09/2012 10:41, Miguel A. Garcia wrote:
>> But the text talks about the what the conference focus sends, not UAs
>> in_general_. If the focus includes anything_other_  than Message/CPIM
>> in accept-types, it better be prepared to receive it. Is that the intent?
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Sep 2012 12:00:51 -0400

On 9/10/12 9:20 AM, Miguel A. Garcia wrote:
> Ben, and the SIMPLE WG:
>
> To clarify the usage of accept-types, I propose two paragraphs to
> Section 5.2 (Joining a chat room). The first paragraph is new and
> discusses the participant's SDP. Here, I propose not to add normative
> text mandating the UA to add 'a=accept-types:Message/CPIM' in SDP. The
> reason is that such normative text would require a mechanism for the UA
> to know in advance that it is joining a chat room, perhaps by examining
> the chat room URI. But in general, such mechanism does not exist. The UA
> will create an INVITE request with SDP, not knowing if at the other end
> there is a chat room or a regular user. If this SDP contains
> 'm=message', the attributes included afterwards will be the same, no
> matter whether the participant is joining a chat room or just another
> endpoint. Please verify that the proposed words are acceptable:
> "...needs to include at least...
>

There are possibilities beyond the one mentioned here:
- the participant might send an INVITE without an offer.
- the focus might send the INVITE, with or without an offer.

>     RFC 4975 procedures [RFC4975].

So how about the following instead?

    This specification requires all instant
    messages to be wrapped in a Message/CPIM wrapper [RFC3862].
    Therefore the 'accept-types' attribute for the MSRP message media in
    both the SDP offer and answer need to include at least the value
    'Message/CPIM'. If not, the conference focus will reject the
    request.  The actual instant message payload type is negotiated in
    the 'accept-wrapped-types' attribute in SDP (see RFC 4975 [RFC4975]
    for details).  There is no default wrapped type.  Typical wrapped
    type values can include: text/plain, text/html, image/jpeg, image/
    png, audio/mp3, etc.  It is RECOMMENDED that participant endpoints
    add an 'accept-wrapped-types' attribute to the MSRP 'message' media
    line in SDP, where the supported wrapped types are declared, as per
    RFC 4975 procedures [RFC4975].

>     attribute to the MSRP message media line in SDP containing the

I'm not sure this says quite what you mean either. Couple of issues:

- I guess the intent is that every message sent to/from the focus is
   wrapped in Messsage/CPIM. That is easy for messages *from* the focus.
   But to ensure it for messages *to* the focus I think you are trying
   to say that the SDP *from* the focus must include *only*
   message/CPIM in 'accept-types'. I think the MUST is in the wrong place
   above for that.

- I am a little concerned that if you only allow message/CPIM, that you
   will be cutting off a point of extensibility. Some future extension
   may need to add something that requires a new mime type here -
   presumably one that is a functional superset of message/CPIM. But
   a mandatory requirement to include *only* message/CPIM will exclude
   such a future focus from being backward compatible with this spec.

ISTM that the desired behavior is:

- if focus is the answerer, and the offer doesn't include message/CPIM,
   then it can't support this spec on that m-line. It then MUST either
   reject the m-line, fail the call, or use this m-line in accord with
   some spec other than this one. (E.g. a future extension.)
   If the offer *does* include message/CPIM, and the focus wants to
   use this spec, then it MUST include *only* message/CPIM in
   'accept-types'.

- if the focus is the offerer, and wishes to support this spec, then
   it MUST include message/CPIM in 'accept-types'. It should only
   include other types in 'accept-types' if there are other alternative
   specs is is prepared to support.

I don't have alternative text for that. It may be hard to write, and I'm 
not going to try unless the above is really the intent.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Sep 2012 11:22:10 -0500

>  such a future focus from being backward compatible with this spec.

I'm not sure that's a bad thing, since there's interop behavior that depends on it's use.  If you use something _other_ than message/CPIM, some one will need to specify how you handle the behavior that is dependent on it.

A possible compromise might be something like "SHOULD include only message/CPIM. While other types might be useful in the future, their use is out of scope for this specification. Any chat mechanism that uses a wrapper other than message/CPIM will need to specify how to encode and interpret sender and recipient information to achieve similar behaviors as in this document."

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Sep 2012 12:49:43 -0400

> I'm not sure that's a bad thing, since there's interop behavior that depends on it's use.  If you use something _other_ than message/CPIM, some one will need to specify how you handle the behavior…

The issue is with some future implementation that supports simple-chat 
and simple-chat-bis that uses message/CPIM++. The problem then arises 
only in the case that the focus generates the offer. It then wants to 
put "message/CPIM,message/CPIM++" in 'accept-types'.

This should be fine for answerers that support only simple-chat as long 
as they don't get over-picky and declare the focus non-compliant for 
mentioning message/CPIM++. So it's just a matter of not forbidding the 
focus from including something else.

> A possible compromise might be something like "SHOULD include only message/CPIM. While other types might be useful in the future, their use is out of scope for this specification. Any chat mechanis…

Yes, something like that could work.

	Thanks,
	Paul

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 12 Sep 2012 14:31:57 +0200

Hi Paul:

Thanks for your comments. See inline.

>      RFC 4975 procedures [RFC4975].

Your proposed text works for me. I will change it.

>     message/CPIM in 'accept-types'. I think the MUST is in the wrong place

Yes, you got the intention of the text. To clarify: SDP sent from the UA 
to the focus need to contain Message/CPIM, but most likely, it will 
contain something else, because the endpoint does not know it is 
connecting to a chat room.

SDP sent from the focus to the UA will only contain an 'accept-types' of 
Message/CPIM, in order to force UAs to send only MSRP messages containing 
Message/CPIM. Therefore, I believe the following MUST is correct:

    'Message/CPIM'.

>     such a future focus from being backward compatible with this spec.

I don't think so. Future extensions will update this draft/RFC. We have 
done it this way many times, when some normative text is updated by a 
subsequent document. So, I don't believe we are cutting off extensibility.

>     use this spec, then it MUST include *only* message/CPIM in

The above is correct. But I don't want to enter the future extensibility 
trap. We should publish normative statements for this document. Future 
documents will have to update this done in many places, I guess.

>     specs is is prepared to support.

Yes, modulo the future extensibility issue.

> not going to try unless the above is really the intent.

So, the text is much easier if you don't consider the future 
extensibility now, but leave it as a future exercise. I believe that the 
text in the draft is correct (with the modifications you suggested at the 
beginning of this message).

BR,

         Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 12 Sep 2012 14:38:33 +0200

Ben, Paul:

See inline comments

On 10/09/2012 18:49, Paul Kyzivat wrote:
>>> - I am a little concerned that if you only allow message/CPIM,
>>> that you will be cutting off a point of extensibility. Some future
>>> extension may need to add something that requires a new mime type
>>> here - presumably one that is a functional superset of
>>> message/CPIM. But a mandatory requirement to include *only*
>>> message/CPIM will exclude such a future focus from being backward
>>> compatible with this spec.
>>
>> I'm not sure that's a bad thing, since there's interop behavior that
>> depends on it's use.  If you use something _other_ than
>> message/CPIM, some one will need to specify how you handle the
>> behavior that is dependent on it.
>
> The issue is with some future implementation that supports
> simple-chat and simple-chat-bis that uses message/CPIM++. The problem
> then arises only in the case that the focus generates the offer. It
> then wants to put "message/CPIM,message/CPIM++" in 'accept-types'.
>
> This should be fine for answerers that support only simple-chat as
> long as they don't get over-picky and declare the focus non-compliant
> for mentioning message/CPIM++. So it's just a matter of not forbidding
> the focus from including something else.
>
>> A possible compromise might be something like "SHOULD include only
>> message/CPIM. While other types might be useful in the future, their
>> use is out of scope for this specification. Any chat mechanism that
>> uses a wrapper other than message/CPIM will need to specify how to
>> encode and interpret sender and recipient information to achieve
>> similar behaviors as in this document."
>

I would accept that compromise if there is a lot of pressure. Let's be 
pragmatical. The Internet is full of RFCs with normative statements that 
have been updated by other documents changing the initial normative 
behavior. This is a common practice in IETF documentation.

So, I don't see a problem in leaving the text as is, and then, if need 
arises, create another hypothetical document that updates this in a 
number of normative statements for the addition of a few hypothetical 
features.

And this will make the current text very clear: "if you implement THIS 
spec you need to do this". If you implement some other spec, that other 
spec will tell you what to do.

/Miguel

>
> Thanks, Paul _______________________________________________ Simple
> mailing list [email-masked]

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Ben Campbell <[email-masked]>
Date: Wed, 12 Sep 2012 08:59:15 -0500

On Sep 12, 2012, at 7:38 AM, "Miguel A. Garcia" <[email-masked]> wrote:

[...]

> I would accept that compromise if there is a lot of pressure. Let's be pragmatical. The Internet is full of RFCs with normative statements that have been updated by other documents changing the initial normative behavior. This is a common practice in IETF documentation.
> 
> So, I don't see a problem in leaving the text as is, and then, if need arises, create another hypothetical document that updates this in a number of normative statements for the addition of a few hypothetical features.
> 
> And this will make the current text very clear: "if you implement THIS spec you need to do this". If you implement some other spec, that other spec will tell you what to do.
> 

WFM