Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - nits

From: Ben Campbell <[email-masked]>
Date: Fri, 1 Oct 2004 17:37:41 -0500

On Sep 24, 2004, at 11:19 AM, Paul Kyzivat wrote:

> I just did a fairly careful review of
> draft-ietf-simple-message-sessions-08. I came up with a bunch of 
> comments.
>
> I will include the nits here, but in the interest of discussion I will
> break the rest up into a number of separate threads.
>
> 	Paul
>
> Section 3, near the end: "This document specifies MSRP behavior only
> peer-to-peer session...". Is awkward wording. Suggest inserting "for a"
> in front of "peer-to-peer".

Typo. Will fix.

>
> Section 4.3, last paragraph: "... but some other systems choose to use 
> a
> value of "partial" to reduce the load on the servers caused by 200 OK
> responses, but still allow error responses to be sent in many cases."
> This will make sense later, but it doesn't make sense at this point in
> the document because the linkage between the report and the 200 hasn't
> been made. Suggest something like:
>
> "... but some other systems choose to use a value of "partial" to 
> reduce
> the load on the servers. As will be seen in section 6.2, this will omit
> 200 OK responses and the load they cause, but still allow error
> responses to be sent in many cases."
>

OK.

> Section 4.4, 4th paragraph from end, there is a sentence fragment that
> should be combined with the next sentence:
> "If the receiving endpoint receives more than one message with the same
> Message-ID. It SHOULD assume that the messages are duplicates."
> Should be:
> "If the receiving endpoint receives more than one message with the same
> Message-ID it SHOULD assume that the messages are duplicates."
>

OK.

> The word "insure" is used twice in this document, and in both cases is
> should be "ensure".
>

Oops. I usually gripe at _other_ people about that one...

> Section 6.1.2 says: "An MSRP endpoint MUST be able to generate success
> REPORT requests." But nowhere do I find a comparable statement about
> failure reports. I think the endpoint MUST be able to do both.
>

That was not the intent. Endpoints would use transaction responses to 
indicate an error. I thought we had discussed that only relays would 
normally send failure reports.

> Section 6.1.3, 1st paragraph: there is an instance of "respons" that
> should be "response".

ok.

>
> Section 6.3.1: s/If chunks data/If chunk data/
>

ok.

> Section 7.1 says to use "*" to indicate willingness to accept any
> content type. This has always seemed gratuitous to me, since the mime
> syntax for types already allows "*/*" to mean that. I think it would
> minimize future issues if we just accepted that instead of specifying
> "*" as a special case. This would require a small change to the syntax 
> of 'type' and 'subtype'.
>

I agree, and will change if no one objects.

> Section 7.1 uses both "container types" and "compound types" to mean 
> the
> same thing. Can we just pick one and stick with it? (I don't care which
> one.)

OK. (Except for every seventh reference, which I will call "complicated 
types". ;-)  )

>
> Section 7.1.5 says: "Instead, MSRP now specifies a default connection
> direction." Its not a default, since you can't change it. I think what
> is meant is: "MSRP now associates connection direction with the
> direction the offer travels."

it is default, in the sense that we have language (or intended to have 
language; Orit indicated it may not be there) to the effect that if 
endpoints have some other agreed upon way to negotiate direction, they 
can override this. The point was to allow people to use something like 
comedia in the future.

>
> Section 10.5: Shows using a REGISTER to query for the contacts. There
> really isn't anything wrong here, but it may cause some readers to
> conclude that using REGISTER this way is something that should normally
> be done. Might be worth a disclaimer that this is only shown for
> purposes of clarifying the example.

Agreed. I am tempted to drop the register altogether and just say that 
the "proxy learns from the location service..."

>
>
>
>
> _______________________________________________
> 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: Tue, 05 Oct 2004 10:24:37 -0400

> Oops. I usually gripe at _other_ people about that one...

I'm just being picky. I'm sure you will return the favor some day. :-)

> normally send failure reports.

Oh, I guess that is ok. So and endpoint must be able to send a failure 
response, but sending failure reports is optional and only needed if it 
is structured so that it sends a success response and can still later 
detect an error.

> can override this. The point was to allow people to use something like 

OK - if there really is the possibility of doing something else.

But that does make me a little uncomfortable, because it reeks of 
private agreements that don't interoperate.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 5 Oct 2004 17:28:32 -0500

On Oct 5, 2004, at 9:24 AM, Paul Kyzivat wrote:

[...]

>> it is default, in the sense that we have language (or intended to 
>> have language; Orit indicated it may not be there) to the effect that 
>> if endpoints have some other agreed upon way to negotiate direction, 
>> they can override this. The point was to allow people to use 
>> something like comedia in the future.
>

The intent is to allow us to incorporate some new _standard_ for this, 
if one appears in the future, not to encourage proprietary agreements. 
I would be happy to entertain any better language for this.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Oct 2004 18:59:37 -0400

Ben Campbell wrote:
> if one appears in the future, not to encourage proprietary agreements. I 
> would be happy to entertain any better language for this.

OK. I'm convinced.

	Paul