Subject: Re: [Simple] MSRP update

From: Miguel Garcia <[email-masked]>
Date: Thu, 01 Apr 2004 18:24:01 +0300

Ben:

Thanks for posting "working versions". I have a few comments:

1) By reading sections 6.4 and 6.5, it is not clear to me, in case the 
a=path contains several URLs, which one represents the endpoint and 
which one the relays.

In 6.4 you wrote: "If the path attribute received from the peer contains 
more than one URL, then the remote URL is the first one".

So I would expect a=path:remote_host, relay_2, relay_1

However, in 6.5, you wrote: "When an endpoint receives more than one URL 
in a path header, only the first entry is relevant for purposes of 
resolving the address and port, and establishing the network connection".

According to 6.4, the first entry points to the remote host, not the 
relay, but I would expect the endpoint to establish a connection to the 
relay.

I see a mismatch between 6.5 and 6.5. Perhaps you can clarify this in 
the draft.

2) Connection management (section 7.2). It is written that an endpoint 
should re-use an existing connection when the peer URL matches the host 
part. Isn't this in contradiction with the text in section 5.1 that 
says, when a large file is to be sent, the endpoint should create a new 
MSRP session to avoid blocking? I would expect that "creating a new 
session" comprises creating a new TCP connection as well, not re-using 
an existing one.

We have similar procedures in 7.5.1, second bullet point for the answer.

3) I noticed the Content-Type is now an MSRP header, but the content is 
a quoted string. Is there any reason to have a quoted string there? I 
noticed that SIP and HTTP does not encode this header field value in quotes.

4) If you remember and old e-mail I sent you some time ago, the MSRP URL 
misses the "@" sign after the "userinfo". Also, there is a mixture of 
quotes (" and '). IMHO the correct definition should be:

  msrp_url = "msrp://" [userinfo "@"] hostport ["/" resource]

Regards,

       Miguel

Ben Campbell wrote:

> The chairs have requested that we put MSRP on a "release early and 
> often" track. That is, rather than waiting until I have all the planned 
> updates completed, I will put out a revision for each significant update.
> 
> Therefore I will be submitting a revised MSRP base spec draft either 
> this evening (Wednesday) or Thursday, followed by a series of revisions 
> over the next few weeks.
> 
> This revision will include changes to MSRP URL handling and connection 
> handling needed to allow relays to be used. As we discussed in Korea, it 
> will not describe relays themselves; this will be handled in a separate 
> draft. But there were a number of base specification changes needed to 
> make it possible to integrate relays.
> 
> We are working from a number of assumptions about how relays will work, 
> even though the MSRP relay draft is pending:
> 
> --Relays are session-stateless
> 
> --Relay chains are source routed, with the route negotiated in the SDP.
> 
> -- Transactions are hop-by-hop, and downstream transactions do not 
> depend on upstream transactions.
> 
> Specific changes in this revision:
> 
> -- The answerer always opens the TCP connection to the offerer. The 
> comedia like direction negotiation is removed.
> 
> --  Shared connections are allowed.
> 
> --  MSRP URLs identify a destination within a session, rather than the 
> entire session itself. MSRP requests will now have a To field describing 
> the destination, and a From field describing the source. The sdp 
> negotiation allows each endpoint to contribute its URL.
> 
> -- To enable routing across relays, an SDP request can carry a list of 
> URLs. We expect this to be used with relays to describe a route across 
> relays. The base spec will not say how one would determine a list of 
> more than one URL, but it does require an endpoint to be able to receive 
> such a list and process it reasonably. Basically, if you receive a list, 
> you put the entire list in To headers on SEND requests. This will work 
> even if the receiver wants to contribute their own relays to the path, 
> but that belongs in the relay spec, not the base.
> 
> There are still a number of outstanding items we discussed in Korea,that 
> will be required to allow relay integration, but are not covered by this 
> revision:
> 
> -- DSN handling and negotiation. Since relays will be able to originate 
> DSNs, even endpoints that don't understand relays will need to be able 
> to receive them.
> 
> -- Chunking
> 
> -- Using message bounderies instead of length fields for message 
> framing, so you can abort a request without destroying framing for the 
> connection.
> 
> -- Orit requested that we allow a mode where there are no transaction 
> responses. She has agreed to document the motivation for this. I will 
> hold any changes based on this request until after the work group has a 
> chance to discuss that document.
> 
> -- a few outstanding, non-controversial items, such as allowing all 
> standard MIME headers.
> 
> Watch this channel for revisions covering these items in the very near 
> future.
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

-- 
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: Ben Campbell <[email-masked]>
Date: Thu, 01 Apr 2004 10:04:48 -0600

> So I would expect a=path:remote_host, relay_2, relay_1

The idea is, the remote host is the one an endpoint actually connects to 
and visits. So if you had relays, the remote URL actually points to a 
relay. So you would really be looking at:

a=path:relay_1, relay_2, remote_host.

> resolving the address and port, and establishing the network connection".

A non-relay aware endpoint really only ever has to care about the first 
entry. It includes the entire path in the To headers so that any relays 
can do the right thing.

> I see a mismatch between 6.5 and 6.5. Perhaps you can clarify this in 

Do you mean between 6.4 and 6.5? Or do I have a section number conflict?

I can see how the current wording is confusing. I struggled with the 
terminology here, and am very open to suggestion. Particularly if we 
decide an endpoint needs to distinguish between the first-hop URL and 
the remote-host URL for any reason.

> We have similar procedures in 7.5.1, second bullet point for the answer.

Yes, that needs to be rationalized. I believe I put in an open issue 
asking if we need to discuss situations where an endpoint would 
intentionally choose not to share a connection between session. (Unless 
I forgot. It happens).

There have been suggestions that we would remove the suggestion to 
create a new session once we have chunking described in the draft. Does 
anyone have thoughts on this point?

> noticed that SIP and HTTP does not encode this header field value in 

I honestly don't remember why we chose quoted-string. It is possible 
there was no good reason. I will check into this. (If anyone remembers, 
please speak up now.)

>  msrp_url = "msrp://" [userinfo "@"] hostport ["/" resource]

Darn. I thought I had fixed than in the _previous_ version. I will fix 
in the next.

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 01 Apr 2004 18:24:01 +0300

Ben:

Regards,

       Miguel

---

From: Ben Campbell <[email-masked]>
Date: Thu, 01 Apr 2004 10:04:48 -0600

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 02 Apr 2004 09:21:00 +0300

Hi Ben:

With respect my first point, I think I understand what is not clear: the 
term "remote host"  or "remote URL". I expected that to be peer host, 
not the "next hop".

I agree that an MSRP endpoint does not need to distinguish between the 
next hop and the peer end, but the protocol specification should clarify 
when we are speaking about the next hop and when about the remote 
endpoint. If you can make such distinction, it would be great.

And yes, I meant 6.4 and 6.5 ;-)

     Miguel

Ben Campbell wrote:

>> In 6.4 you wrote: "If the path attribute received from the peer 
>> contains more than one URL, then the remote URL is the first one".
>>
>> However, in 6.5, you wrote: "When an endpoint receives more than one 
>> URL in a path header, only the first entry is relevant for purposes of 
>> relay, but I would expect the endpoint to establish a connection to 
>> the relay.
>>
>> should re-use an existing connection when the peer URL matches the 
>> host part. Isn't this in contradiction with the text in section 5.1 
>> that says, when a large file is to be sent, the endpoint should create 
>> a new MSRP session to avoid blocking? I would expect that "creating a 
>> new session" comprises creating a new TCP connection as well, not 
>> re-using an existing one.
>>
>> 3) I noticed the Content-Type is now an MSRP header, but the content 
>> is a quoted string. Is there any reason to have a quoted string there? 
>> I noticed that SIP and HTTP does not encode this header field value in 
>> quotes.
>>
>>
> 
>> 4) If you remember and old e-mail I sent you some time ago, the MSRP 
>> URL misses the "@" sign after the "userinfo". Also, there is a mixture 
>> of quotes (" and '). IMHO the correct definition should be:
>>

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 02 Apr 2004 09:21:00 +0300

Hi Ben:

     Miguel