Subject: Re: [Simple] message-sessions-10 WGLC comments

From: Ben Campbell <[email-masked]>
Date: Wed, 6 Apr 2005 22:00:40 -0500

Thanks for the feedback. Comments inline:

On Mar 25, 2005, at 1:54 PM, Pekka Pessi wrote:

> Hello all,
>
> I've a few comments, but managed to find only a couple of nits...
>
> --Pekka
>
> Comments:
>
> 7. Method-Specific Behaviour
>
> The structure of the section is a bit confusing, as the spec first
> handles sending requests and then receiving them, but base MSRP
> only has these two methods... Perhaps first handle delivering
> SEND, then receiving SEND, delivering REPORT and finally receiving
> REPORTs?
>

We chose this structure on purpose, so areas of commonality would not 
have to be respecified for each method. Given the extensions in the 
relay draft, I think this approach makes sense. Therefore I would 
prefer to keep this as is unless lots of people want to change it. Do 
others want to see a change here?

> - Is the 30 second reasonable value for delivery timer (used in
>   Failure-Report: yes case)?

It is in fact rather arbitrary. The WG discussed this on several 
occasions, and no one could offer a way to determine a truly 
appropriate value. So we picked on.

>  When the timer is started? (When the
>   application send()s last bytes? When bytes were first delivered
>   to network? Delivered to network interface? User-space TCP
>   stacks are not so common, even less common than user-space
>   device drivers or proper QoS implementation. I bet we can do
>   this on Nokia handset but on a node running Windows or Linux???)
>

I think this can only mean you start the timer when you have delivered 
all the bytes to the stack for sending. Nothing else makes sense in any 
portable fashion. I will attempt to clarify this.

> - Report-Failure, Report-Success headers
>
>   Should it be up to the extension method to define whether these
>   are included in the request?

Yes. This is already a planned change.

>  In any case, if an endpoint (node?)
>   does not understand request, should it return a 501 response?
>

501 just means that the recipient does not understand the method. If 
the method is known, but the request is otherwise unintelligible, the 
response should be 400.

>   Perhaps:
>
>    Success-Report and Failure-Report MUST NOT be present in REPORT
>    request.
>
>   The default behaviour in absense of Success/Failure-Report could
>   be defined in base spec, for instance, Success-Report: no and
>   Failure-Report: yes.
>
> 8.1.4 Updated SDP Offers
>
> - Does it create a new session when the MSRP path changes?

I think it does. One could argue that as long as the endpoint URIs do 
not change, it is the same session. But I think that adds too much 
complexity; it is easier to just consider it a new session.

> When the
>   new session is created and when the old one ends? What if the
>   party is returned a 481 response? With old path? With new path?
>

I'm not sure I follow your meaning.

>   I'd propose that changing the path should only be possible when
>   a offer is sent in INVITE (or similar non-SIP method where the
>   user/UA intervention is possible).

Not sure about this one--does anyone else have comments?

>
> 9. Syntax
>
> - I'd propose that the spec explicitly mention to extensibility of
>   MSRP URLs with parameters:
>
>    MSRP-URL = msrp-scheme "://" [userinfo "@"] hostport
>               ["/" session-id] ";" transport *ext-url-param
>
>    ext-url-param = ";" 1*unreserved [ "=" 1*unreserved ]
>
>

This seems reasonable.

> NITS:
>
> 7.3.2 MSRP Modes => MSRP nodes
>
> 9. rfc2396bis is nowadays RFC 3986 STD 66.
>
>
>
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
>

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Apr 2005 09:22:00 -0400

> portable fashion. I will attempt to clarify this.

This is part of a bigger question. Not only this, but chunking behavior 
too, seems to require a more intimate relationship to the TCP stack than 
may typically be available. If the stack does a lot of its own 
buffering, then it becomes hard to behave as expected. (I may be trying 
to send the LoTR. My attempt to write may queue up much more than 2k. 
That makes it hard to break in with other messages.)

I have been ignoring this as an implementation issue. But I'm waiting to 
hear somebody complain about it.

	Paul