Subject: [Simple] Comments to MSRP-10

From: Miguel Garcia <[email-masked]>
Date: Tue, 01 Mar 2005 16:13:34 +0200

I am sending a few comments to version -10 of MSRP. They are mostly 
editorials.

1) Section 5.3, at the end of the 4th paragraph, the text reads:

    "A Failure-Report of "partial" is a way to report
    errors except timeouts.  The timeout error reporting requires the
    sending hop to run a timer and that receiving hop to send an
    acknowledgment to stop the timer.  Some systems don't want the
    overhead of doing this so choose not to but still allow error ..."

Well, in my opinion the sentence about the timeout is unintelligible, 
because this is the first time in the document we speak about timeouts, 
and people won't understand where this timeout can occur.

Since section 5 is informative in nature, I believe there is not hurry 
to discuss the timeout, which is further and well discuss later in the 
document.

So I would suggest that Section 5.3 just indicates that Failure-Report 
can also take the value "partial", and that the concept is further 
described in Section 7.1.1.

Alternatively you may want to add a full description of the timer, the 
timeout and the value of "partial", but I don't think it is needed in 
this section.

2) Section 5.4, 3rd paragraph:

    "Likewise, the active endpoint MUST immediately issue a SEND request.
    This initial SEND request MAY have a empty body, or MAY carry
    content."

I would like to see some motivational text for such requirement.

3) Section 5.4, 8th paragraph, purely editorial

    "If the receiving endpoint receives more than one message
    with the same Message-ID.  It SHOULD assume that the messages are
    duplicates."

This should be just one sentence separated by a comma, rather than two 
sentences separated by a colon.

4) Section 5.4, 8th paragraph, next sentence to the above point:

    "It MAY take any action based on that knowledge, but
    SHOULD NOT present the duplicate messages to the user without warning
    of the duplication."

I believe it there is normative text, even a "MAY", we should indicate 
what this action is, otherwise it is useless to have "you MAY do 
something" because the MAY should indicate a protocol implementation 
option, which is not the case.

5) Section 7.1, 2nd paragraph:

    "It may contain other MIME specific
    headers."

    s/may/MAY because this is clearly normative text.

6) Section 7.1.1., 6th paragraph:

    "Success-Report and Failure-Report MUST NOT be present for any method
    other than SEND.  "

I would like to change the above sentence to be positive, rather than 
negative, and add some scope. The motivation is that, in the future, we 
may need to extend MSRP with a new method that contains Failure-Report 
and Success-Report, and in such case we will be violating the above 
text. So what about this:

    "Within the scope of the methods defined by this document, 
Success-Report and Failure-Report headers MUST only be present (if 
required) in SEND requests".

7) Section 7.3.1, last paragraph in the section

    "If the Success-Report header was set to "yes", then when a complete
    message has been received, the receiver MUST send a success REPORT
    with a byte range covering the whole message.  If the Success-Report
    header is not set to "no", then the receiver MAY generate incremental
    success REPORTs as the chunks are received.  These can be sent
    periodically and cover all the bytes that have been received so far
    or they can be sent after a chunk arrives and cover just the part
    from that chunk."

So, if I understand correctly, the receiver has the right to send 
success REPORTs of chunks when the Success-Report is se to "no". Is this 
correct?

If it is, I find very weird that a receiver generate Success Reports of 
chunks whenever it wants, especially when the sender has indicated that 
it does not care to know when the complete message is finally received. 
Actually, we don't have a mechanism for the sender to request REPORTs of 
chunks (we do have a mechanism to request reports for the whole 
message). But the current behavior, leaving anything in the receiver's 
side, is certainly wrong in my opinion.

Any comments?

8) Section 7.3.2, 3rd paragraph:

    "It is possible to receive a failure report or a failure transaction
    response for a chunk that is currently being delivered.  In this case
    the entire message corresponding to that chunk should be aborted, by
    including the "#" character in the continuation field of the closing
    sequence."

s/should/SHOULD

But also, is it possible to abort a chunk that hasn't been marked as 
interruptible (setting a "*" in the last-byte field of the Byte-Range 
header)? At least section 7.3.1 seems to indicate that it is not legal. 
Therefore, I suggest to scope the above text by indicating this case:

    "It is possible to receive a failure report or a failure transaction
    response for a chunk that is currently being delivered.  In this
    case, if the message is interruptible, the entire message
    corresponding to that chunk SHOULD be aborted, by
    including the "#" character in the continuation field of the closing
    sequence."

9) Section 7.3.2, last sentence

    "MSRP Modes MUST NOT send a MSRP REPORT in responses to REPORT
    requests."

s/Modes/nodes

10) Section 8.1, SDP terminology.

SDP defines its own terminology to refer to the different lines. For 
instance, SDP refers to the "m=" line, as well as the "a=" line. But 
MSRP refers to the media-line and the a-line. I suggest to use the SDP 
terminology.

11) Section 8.1.6.

This section seems to include some historical information that won't be 
applicable once the I-D is published as RFC, so I would suggest to 
remove this section entirely.

12) Section 9. Status namespace:

The Status is defined as:

    Status = "Status:" SP namespace SP status-code [SP text-reason]
    namespace = "000"

I disagree with having the namespace specified in the ABNF. The purpose 
of the namespace is to add extensibility to the status, but by adding 
namespace to the ABNF the extensibility is cut.

I suggest to have a namespace defined as a string of digits, and 
somewhere in the spec explain (if required, I believe it is already 
explained) that this specification describes namespaces 000 that map to 
response codes. So I suggest to define namespace as:

    namespace = *3DIGIT

13) Section 9. alphanum and ALPHANUM

The section, in several places, sometimes refers to alphanum and 
sometimes to ALPHANUM. I guess it should always be ALPHANUM.

14) Section 11. Spaces

Most of the examples don't contain a space (SP) in between the From-Path 
and the URI. The same also applies to the To-Path and Content-Type. So I 
suggest to do the next global replaces:

s/To-Path:msrp:/To-Path: msrp:
s/From-Path:msrp:/From-Path: msrp:
s/Content-Type:application/Content-Type: application

15) Sections 5.1 and 11.1. Length of Message-ID value.

According to the ABNF, Message-ID is defined as:

    Message-ID = "Message-ID:" SP ident
    ident = alphanum  3*31ident-char

This means that the value in Message-ID should contain at least 4 
characters (one alphanum and a minimum of 3 ident-char).

However, some examples in Sections 5.1 and 11.1 contain a Message-ID 
with only 3 digits. So add one more character to those examples.

16) Section 14.2. 1st paragraph reads:

    "If S/MIME is supported, SHA-1, RSA, and AES-128 MUST be supported."

Since this is a normative statement, I would suggest to add normative 
references to all S/MIME, SHA-1, RSA, and AES-128.

17) Section 14.2. The 2nd paragraph starts with:

   "This does not actually require the endpoint to have certificates from
    a well known certificate authority. "

I fail to put that sentence into context. What is it that does not 
require certificates from a CA, the previous paragraph or the paragraph 
beginning with that sentence. I suspect it is the latter, in which case 
I will suggest to replace that sentence with:

"In another scenario, MSRP can be used without requiring the endpoints 
to have certificate from a well known certificate authority. In this 
case ... [bla bla]".

18) Section 18, References.

The following references are listed in Section 18, but never referred to 
from the text.

[1], [7], [8], [26]

I believe all of them should be referred from the main text of the spec. 
I will leave to your judgement to decide where to include the reference 
to the appropriate spec.

That's all. BR,

          Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Mar 2005 12:09:42 -0500

Miguel - some good catches. A couple of comments.

	Paul

> required) in SEND requests".

I don't find that helpful. I understand what the original is requiring, 
but with your suggestion I don't.

> success REPORTs of chunks when the Success-Report is se to "no". Is this 

I don't understand it that way. I believe it specifies:

	YES: MUST send success report for complete message,
	     MAY send incremental success reports

	NO:  MUST NOT send success reports at all

	PARTIAL: MAY send success reports, either for the
	     complete message or incrementally.

> side, is certainly wrong in my opinion.

I was in favor of a more explicit mechanism for dealing with incremental 
reporting, but it got compromised away in the interest of progress.

>    including the "#" character in the continuation field of the closing

I guess this doesn't hurt. In practice I doubt it can happen, since an 
uninteruptible chunk can't be larger than 2k, and it seems unlikely that 
you would hear about an abort for it while it was still not all 
transmitted. (Note that in this case transmitted only means handed off 
to the OS of your node.)

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 01 Mar 2005 19:40:41 +0200

Paul:

Some comments inline, prepended by "Miguel -> "

Paul Kyzivat wrote:

>> negative, and add some scope. The motivation is that, in the future, 
>> we may need to extend MSRP with a new method that contains 
>> Failure-Report and Success-Report, and in such case we will be 
>> violating the above text. So what about this:
>>

Miguel -> I don't really care about the exact wording, as long as it 
does not make any assumptions about future MSRP extensions. The current 
text implies that the Report headers are meant only for SEND requests, 
and for no other MSRP methods that any human can think of in the future. 
So if we invent a new method that can use those headers, this shouldn't 
create a violation of the MSRP RFC.

>> success REPORTs of chunks when the Success-Report is se to "no". Is 
>> this correct?
> 
> 

Miguel -> This is not according to the current text, that says: If the 
Success-Report header is not set to "no", then the receiver MAY generate 
incremental success REPORTs as the chunks are received.

>          complete message or incrementally.

Miguel -> I think this is not written in the text.

> 
>> If it is, I find very weird that a receiver generate Success Reports 
>> of chunks whenever it wants, especially when the sender has indicated 
>> that it does not care to know when the complete message is finally 
>> received. Actually, we don't have a mechanism for the sender to 
>> request REPORTs of chunks (we do have a mechanism to request reports 
>> for the whole message). But the current behavior, leaving anything in 
>> the receiver's side, is certainly wrong in my opinion.
>>
>> Any comments?
> 
> 

Miguel -> I don't really know what would be the benefit of getting such 
incremental report. Is it to allow the sender an early recovery of a 
failure? In this case it would be governed by the Failure-Report header, 
  or an error response.

Miguel -> So I am leaning towards thinking that the chunk reports are 
useless. But in any case, if we decide to keep them in the spec, they 
should be sent only when requested by the sender, rather than 
arbitrarily from the receiver. One can think of a new parameter to the 
Success/Failure-Reports indicating whether the report generation applies 
also to chunks, but I am not convinced that chunk reports are needed at all.

BR,

      Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Mar 2005 13:03:02 -0500

more inline

	Paul

Miguel Garcia wrote:
>> I don't find that helpful. I understand what the original is 
>> requiring, but with your suggestion I don't.
> 
> create a violation of the MSRP RFC

OK. I can buy that. I see two ways to achieve that:
- Say that Success-Report and Failure-Report MUST NOT be used in a
   request or response unless permitted by specific normative text.
   The normative text will only be present for SEND.

- Introduce a table like Table 2 of 3261 (I think it is table 2),
   specifying which headers may be used with which requests and
   responses.

I prefer the table.

> incremental success REPORTs as the chunks are received.

Agree, this isn't explicit in the above paragraph. So we should add 
another sentence to the end of the above:

"If the Success-Report header was set to "no", then success reports MUST 
NOT be sent."

> Miguel -> I think this is not written in the text.

Well, "partial" is not NO, so it may send an incremental report. And a 
report for the complete message is indistinguishable from an incremental 
report so that is permitted too.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 01 Mar 2005 20:19:13 +0200

Inline.

Paul Kyzivat wrote:

>>>> I would like to change the above sentence to be positive, rather 
>>>> than negative, and add some scope. The motivation is that, in the 
>>>> future, we may need to extend MSRP with a new method that contains 
>> does not make any assumptions about future MSRP extensions. The 
>> current text implies that the Report headers are meant only for SEND 
>> requests, and for no other MSRP methods that any human can think of in 
>> the future. So if we invent a new method that can use those headers, 
>> this shouldn't create a violation of the MSRP RFC
> 
> 

I know that some people hates this table... but I am fine with it, I 
find it very useful.

>> Success-Report header is not set to "no", then the receiver MAY 
>> generate incremental success REPORTs as the chunks are received.
> 
> 

I agree that "partial" is not NO. I am just saying that the text does 
nos say anything about "partial" and incremental reports.

But still I haven't found an answer to what is the usefulness of reports.

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Mar 2005 09:24:42 -0500

Miguel Garcia wrote:

>>> requests, and for no other MSRP methods that any human can think of 
>>> in the future. So if we invent a new method that can use those 
>>> headers, this shouldn't create a violation of the MSRP RFC
>>

I'm not wild about the table either, but it seems to beat the alternatives.

>>> Miguel -> This is not according to the current text, that says: If 
>>> the Success-Report header is not set to "no", then the receiver MAY 
>> "If the Success-Report header was set to "no", then success reports 
>> MUST NOT be sent."
>>
>> report for the complete message is indistinguishable from an 
>> incremental report so that is permitted too.
> 

Doesn't seem to be an issue.

> But still I haven't found an answer to what is the usefulness of reports.

They are useful in recovering from loss of the media connection. You can 
reestablish the connection (with reinvite) and then restart sending the 
message. Any ranges that were confirmed don't have to be sent again. 
When the connection hasn't failed, the success reports indicate portions 
of the message that no longer need to be saved to prepare for error 
recovery.

This might be significant in our frequently cited case of transmitting 
the Lord of the Rings. (The fact that we use that as an example says 
something about how long we have been working on this.)

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 05 Mar 2005 08:35:16 -0800

Miguel -  thank you for the detailed review and comments - they are great.

Inline ... 

> I'm not wild about the table either, but it seems to beat the alternatives.

I don't like table 2 in 3261 and think it has done more harm than good. I
understand what you want to accomplish here and am fine with that. We need
to think a little about how a relay would know how to handle a unknown
request. I think we could switch this to just say that Reports where not
allowed for REPROT and AUTH messages.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 05 Mar 2005 08:52:02 -0800

Ok - I got lost on this thread. Do we need to change any text. I'm fine to
add in the suggested

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 05 Mar 2005 12:34:30 -0500

Yes, I think making that change would clarify a fuzzy spot.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Sat, 05 Mar 2005 20:00:52 +0200

Yes, please. This solves one bug in the current text.

But I'm still not happy leaving the decision of whether to send 
incremental reports in the receiver's hands. The same that other types 
of reports are requested by the sender, incremental reports should be 
requested by the sender.

One possible solution is to add a parameter to the Success-Report 
header, so that when it takes the value yes, it can also take the 
parameter "incremental", meaning that the sender is willing to receive 
incremental reports.

How about that?

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Sat, 05 Mar 2005 20:03:01 +0200

Any of the proposals look good to me. The point is not to put normative 
text for future yet unknown extensions.

/Miguel

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 05 Mar 2005 11:28:09 -0800

I would really rather not add yet another variation to the error reporting
unless we really needed it.

We can't really put a flag that says the receiver must send incremental
reports because a relay before the endpoint may aggregate all the chunks
into a single one there would be only a single report.

We could put a flag that said the receiver MUST NOT generate incremental
success reports. A system that did this would really hamper it's ability to
recover from errors and eliminate any intermediate feedback that it received
about ongoing transfers. All the cases I can think of where you would want
this, you would probably just say no to Success-Reports all together.

If this turns out to be a mistake, we can easily add it later without
violating any of current text. At one point in time I had a Success-Report
values of yes, no, and no-incremental. That is why some of the text is
somewhat double negative like "if value does not equal no then" so that we
can insert another value in the Success-Report and still have all the
current stuff operate correctly.

So in summary, I think we could do it, but I'd rather not unless we have a
strong need for it. The text is written such that we have an insurance
policy of being able to easily add it later if this was a mistake.

Opinions?

---

From: Adam Roach <[email-masked]>
Date: Sat, 05 Mar 2005 13:34:36 -0600

>policy of being able to easily add it later if this was a mistake.

KISS

/a

---

From: Miguel Garcia <[email-masked]>
Date: Sat, 05 Mar 2005 22:01:24 +0200

Ok, I hadn't considered the operation with relays. I agree with you then.

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 05 Mar 2005 15:19:01 -0500

I can see more work on this in the future, around recoverability, but 
think it is best to leave as is for now. There are multiple 
complications with mandating incremental reports. As mentioned below, 
the UAS may receive it all as one chunk. It is also possible that it 
will receive it as a million tiny chunks, which could result in a flood 
of reports. For a case where a large message is being received 
gracefully in order with no problems, it would probably be good to send 
a report periodically. This would bound the amount of bandwidth consumed 
in reports, yet would minimize what needs to be retransmitted in case of 
an error.

But working out the details of negotiating that would be a lot of 
trouble, so I certainly don't want to do it now, if ever. Both ends have 
an equal interest in this - it minimizes what must be retransmitted and 
so the time they both must wait for that to happen. Since both benefit, 
it seems reasonable to just count on the recipient to make a reasonable 
choice about when and if to send these.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Sat, 5 Mar 2005 21:09:27 -0600

I agree with Cullen on this point.  I have trouble imagining a 
situation where the sender would request success reports, and 
incremental reports would be a problem. Similarly, I don't think we 
want to let the sender _require_ them.

So, the most we would get out of such a parameter is a hint. I don't 
think the value of such a hint is worth adding further complexity to 
the report mechanism--it is complex enough as it it.

---

From: Ben Campbell <[email-masked]>
Date: Sat, 5 Mar 2005 21:09:53 -0600

On Mar 2, 2005, at 8:24 AM, Paul Kyzivat wrote:

[...]

> something about how long we have been working on this.)

Actually, I think  the seminal example was "The Matrix", which dates us 
even further. I note that the latest relay draft merely refers to a 
large mpeg without mentioning specific content. I thought perhaps the 
authors were trying to avoid any suggestion of copyright violation, but 
now I realize it was because they got tired of changing to the latest 
big movie with every version :-)

---

From: Adam Roach <[email-masked]>
Date: Sun, 06 Mar 2005 01:03:20 -0600

Miguel Garcia wrote:

> this shouldn't create a violation of the MSRP RFC.

If I recall correctly, MSRP isn't intended to be method-extensible. Once 
again relying on my memory, I believe that this decision is due to some 
specific guidance that we have received from the IESG by way of our area 
director.

/a

---

From: Miguel Garcia <[email-masked]>
Date: Sun, 06 Mar 2005 21:16:28 +0200

Yeap, I agree with Ben, there is an unknown method response. Actually, 
even the relay spec extends MSRP with the AUTH method, and I think it 
would be a failure if in year 2005 the IETF produces a protocol that is 
not extensible.

/Miguel

Ben Campbell wrote:
> It isn't intended to be _very_ extensible, whatever that means. But we 
> do have a response code for "unknown method" now. It was one of many 
> compromises over the course of this work.
> 
> On Mar 6, 2005, at 1:03 AM, Adam Roach wrote:
> 
>> Miguel Garcia wrote:
>>
>>>
>>> headers, this shouldn't create a violation of the MSRP RFC.
>>
>>
>>
>> If I recall correctly, MSRP isn't intended to be method-extensible. 
>> Once again relying on my memory, I believe that this decision is due 
>> to some specific guidance that we have received from the IESG by way 
>> of our area director.
>>
>> /a
> 
>

---

From: Ben Campbell <[email-masked]>
Date: Sat, 5 Mar 2005 13:33:59 -0600

---

From: Ben Campbell <[email-masked]>
Date: Sun, 6 Mar 2005 08:26:08 -0600

---

From: Ben Campbell <[email-masked]>
Date: Sat, 5 Mar 2005 14:21:16 -0600

[...]

---

From: Robert Sparks <[email-masked]>
Date: Wed, 9 Mar 2005 09:13:47 -0600

MSRP has extension points - methods and headers can be added.

What it doesn't have, and this was something the working group chose to 
do
_on purpose_ (though the consensus was of the rougher form), is a notion
of negotiating use of the extensions _inside MSRP_. There is nothing 
like
a Require header. (This is the discussion Adam is remembering, I think).

The reason is that this protocol is designed to be used ONLY in the 
context
of a rendezvous protocol like SIP (please review the applicability 
statement
to make sure you get this when you read it). In particular,  that 
statement
places the following requirement on the protocol used to set up an MSRP 
session:

       The rendezvous mechanism MUST provide mechanisms for the
       negotiation of any supported MSRP extensions that are not
       backwards compatible.

So - negotiation of extensions/versions/whatever are done when agreeing
to enter into an MSRP session, not during the MSRP session itself.

Magnus was surprised by the lack of a registry for methods and headers.
If the group agrees such a thing would be reasonable, I'll volunteer to 
provide
the text this week. All - please comment.

RjS

On Mar 6, 2005, at 1:16 PM, Miguel Garcia wrote:

> would be a failure if in year 2005 the IETF produces a protocol that 
> is not extensible.
>
> /Miguel
>
> Ben Campbell wrote:
>> It isn't intended to be _very_ extensible, whatever that means. But 
>> we do have a response code for "unknown method" now. It was one of 
>> many compromises over the course of this work.
>>>> Miguel -> I don't really care about the exact wording, as long as 
>>>> it does not make any assumptions about future MSRP extensions. The 
>>>> current text implies that the Report headers are meant only for 
>>>> SEND requests, and for no other MSRP methods that any human can 
>>>> think of in the future. So if we invent a new method that can use 
>>>> those headers, this shouldn't create a violation of the MSRP RFC.
>>>
>>>
>>>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 9 Mar 2005 09:24:00 -0600

At every SIPIt we run into lack of interoperability due to people
enforcing Table 2 blindly instead of paying attention to the normative 
text.

The people that do this learn a lot - and walk away from the experience 
with
a healthy dose how to apply Postel's Maxim to their code, _but_ the 
didn't
work when they walked in because this table mislead them to produce
bad code through its false impression of providing a complete summary.

The table (at least as built into 3261) does more harm than good.

RjS

On Mar 2, 2005, at 8:24 AM, Paul Kyzivat wrote:

>>>> those headers, this shouldn't create a violation of the MSRP RFC
>>>
>>>>>> success REPORTs of chunks when the Success-Report is se to "no". 
>>>>>> Is this correct?
>>>>>
>>> Well, "partial" is not NO, so it may send an incremental report. And 
>>> a report for the complete message is indistinguishable from an 
> They are useful in recovering from loss of the media connection. You 
> can reestablish the connection (with reinvite) and then restart 
> sending the message. Any ranges that were confirmed don't have to be 
> sent again. When the connection hasn't failed, the success reports 
> indicate portions of the message that no longer need to be saved to 
> prepare for error recovery.
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 09 Mar 2005 10:47:43 -0600

I have generally argued against the need for lots of extensibility mechanism
in this protocol. The chat draft brings up an interesting point - regardless
if you thing chat is good or not - this draft shows that many extortions to
MSRP will probably require a new method. This might be fine. The other thing
we could do was say that headers that start with "M-" are mandatory to
understand. Thoughts?

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 9 Mar 2005 17:58:01 +0100

I don't like that. What is the objection with the SDP negotiation 
mechanism?

Hisham

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Mar 2005 12:25:11 -0500

I don't care very much which way is used. The goal is to be unambiguous, 
one way or another. The advantage of a table is that it *should* be 
relatively unambiguous. If the table is just an approximation, to which 
there are a bunch of exceptions, then it starts to lose its value.

	Paul

Robert Sparks wrote:
> a healthy dose how to apply Postel's Maxim to their code, _but_ the didn't

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 09 Mar 2005 11:24:45 -0600

> I don't like that. What is the objection with the SDP negotiation

Fair enough - I'm not actually trying to suggest which is best. I just want
to close this off as soon as possible. The one problem that has been
mentioned with SDP is how to require a relay supports an extension.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 9 Mar 2005 11:28:12 -0600

So far, we have been trying to allow, but not encourage, minimal 
extensibility. I thought we had a working group consensus to not allow 
wholesale extension. In fact, we originally did not have any 
extensibility features, and the one that are currently there are the 
result of various compromises.

Having an ability to negotiate extensions in the protocol itself would 
constitute a new requirement. We _really_ don't want new requirements 
at this point, if we ever plan to finish this.

So, my opinions on the whole thread:

1) Having an IANA registry: I would prefer not. The main reason that I 
would rather not is, the work group has argued this point on multiple 
occasions, and each time the answer came back as no. I do not see any 
new argument that has not been made before, so I don't see a reason to 
readdress that decision.

That being said, my opinion on this is not so strong; if the work group 
chooses to readdress this anyway, and decides to include it, I won't 
argue further.

2) Adding additional extensibility mechanisms to MSRP itself: I 
_really_ don't want to do this, as I see it as yet-another new 
requirement that will require quite a bit of discussion and thought to 
nail down. I am categorically opposed to adding any new requirements at 
this time. We need to finish this. I also note that both SIP/SDP and 
MSRP have features to negotiate allowed content-type, which argues for 
making the payload contents into the primary extension point.

3) People have used the relay draft as a precedent that it is okay to 
do wholesale method extensions. I note that relays are separate from 
the base draft for historical reasons only. I don't see it so much as 
an extension to MSRP, but merely a subset of MSRP that is optional if 
you never need its features. If we were to start over now, the relay 
draft would be part of the base draft. The only reason we did not 
combine them is because we thought that the editorial effort to combine 
the drafts and make sure we had not broken any thing would delay 
completion.

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 09 Mar 2005 17:49:09 +0200

Hi Robert:

Placing a requirement of capability negotiation to the rendezvous 
protocol (SDP) makes me a bit nervous, in the sense that the protocol is 
under control of a different WG and different area in the IETF. I 
wouldn't like to face a situation where a proposal to extend SDP to 
provide capability negotiation of a future MSRP feature is rejected in 
MMUSIC on the basis that MMUSIC does not want to extend SDP.

Particularly, the SDP extensions defined in the MSRP draft allow minimum 
capability negotiation mostly related to the accepted MIME types, but 
not to the MSRP extensions. We have already one extension, namely the 
AUTH method.

Have we discussed with the MMUSIC chairs the willingness of MMUSIC to 
accept such work, in the event it is required in the future?

With respect IANA, my believe is that we need the registry, so I would 
welcome your proposal to open the MSRP registry.

/Miguel

Robert Sparks wrote:

> What it doesn't have, and this was something the working group chose to do
> of negotiating use of the extensions _inside MSRP_. There is nothing like
> The reason is that this protocol is designed to be used ONLY in the context
> to make sure you get this when you read it). In particular,  that statement

---

From: Robert Sparks <[email-masked]>
Date: Wed, 9 Mar 2005 09:53:28 -0600

Miguel -

The rendezvous protocol in this case is SIP.

On Mar 9, 2005, at 9:49 AM, Miguel Garcia wrote:

> protocol (SDP) makes me a bit nervous, in the sense that the protocol 
> is under control of a different WG and different area in the IETF. I 
> Particularly, the SDP extensions defined in the MSRP draft allow 
> minimum capability negotiation mostly related to the accepted MIME 
> types, but not to the MSRP extensions. We have already one extension, 
> namely the AUTH method.
>
>> places the following requirement on the protocol used to set up an 
>> MSRP session:
>> If the group agrees such a thing would be reasonable, I'll volunteer 
>> to provide
>>> Yeap, I agree with Ben, there is an unknown method response. 
>>> Actually, even the relay spec extends MSRP with the AUTH method, and 
>>> I think it would be a failure if in year 2005 the IETF produces a 
>>> protocol that is not extensible.
>>>
>>> /Miguel
>>>
>>> Ben Campbell wrote:
>>>
>>>>>> it does not make any assumptions about future MSRP extensions. 
>>>>>> The current text implies that the Report headers are meant only 
>>>>>> for SEND requests, and for no other MSRP methods that any human 
>>>>>> can think of in the future. So if we invent a new method that can 
>>>>>> use those headers, this shouldn't create a violation of the MSRP 
>>>>>> RFC.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> If I recall correctly, MSRP isn't intended to be 
>>>>> method-extensible. Once again relying on my memory, I believe that 
>>>>> this decision is due to some specific guidance that we have 
>>>>> received from the IESG by way of our area director.
>>>>>
>>>>> /a
>>>
>>>
>>> --

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 09 Mar 2005 18:06:12 +0200

> The rendezvous protocol in this case is SIP.

Sure, but I am still assuming that any extension required by MSRP would 
be negotiated in SDP, right?

/Miguel

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 09 Mar 2005 10:43:35 -0600

The rendezvous protocol can negotiation capabilities of endpoints but is
incapable of negotiating capabilities of relays.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 09 Mar 2005 19:42:06 +0100

Hi,

> chooses to readdress this anyway, and decides to include it, I won't 

In my opinion any protocol function that can be extended at all, really 
should define a registry for it. This independent if one foresee 
extensions or not. If one enable any type of extension, there should be 
established a method for keeping track of that extension.

This is so that one has one place that lists possible values, rather 
than having to dig through potentially numerous RFCs. In this case it 
seems that MSRP protocol specifications will consist of at least two 
RFCs and there seem to be ongoing discussion of further documents. Thus 
it seems reasonable to have an IANA registries for methods, headers, etc.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Mar 2005 13:52:43 -0500

>> this draft shows that many extortions to
>> MSRP will probably require a new method.

I'm pretty sure we shouldn't be encouraging MSRP extortionists.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Thu, 10 Mar 2005 20:05:44 -0600

For the benefit of the list:

I think that, in a hallway conversation we had yesterday, that there 
are in fact possible ways to use the SDP to declare relay capabilities. 
One way (an existance proof, not necessarily the _right_ way) is to 
include parameters in URIs in the path attribute.

On Mar 9, 2005, at 10:43 AM, Cullen Jennings wrote:

>> is
>> minimum
>>> MSRP
>>> to
>>>> Actually,
>>>>>>> The
>>>>>> method-extensible.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 10 Mar 2005 20:07:07 -0600

After several hallway discussions, I am backing away from my opinion 
about the registry. If the work group wants it and the ADs are okay 
with it, I will be happy to add it in.

On Mar 9, 2005, at 12:42 PM, Magnus Westerlund wrote:

>> 1) Having an IANA registry: I would prefer not. The main reason that 
>> I would rather not is, the work group has argued this point on 
>> multiple occasions, and each time the answer came back as no. I do 
>> not see any new argument that has not been made before, so I don't 
>> see a reason to readdress that decision.
>> That being said, my opinion on this is not so strong; if the work 
>> group chooses to readdress this anyway, and decides to include it, I 
>> won't argue further.
>
> In my opinion any protocol function that can be extended at all, 
> really should define a registry for it. This independent if one 
> foresee extensions or not. If one enable any type of extension, there 
> should be established a method for keeping track of that extension.
>
> RFCs and there seem to be ongoing discussion of further documents. 
> Thus it seems reasonable to have an IANA registries for methods, 
> headers, etc.
>
>
> Cheers
>
> Magnus Westerlund
>

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 11 Mar 2005 06:32:45 +0200

I also support this idea. I think it might be worth discussing what is 
the policy for IANA registration of new methods, headers, and values. I 
would expect something on the lines of SIP.

/Miguel

Ben Campbell wrote:

> about the registry. If the work group wants it and the ADs are okay with 
> it, I will be happy to add it in.
>