Subject: [Simple] Re: Comments on draft-ietf-simple-message-sesisons-00

From: Ben Campbell <[email-masked]>
Date: 28 May 2003 21:00:42 -0500

Sorry for not responding sooner--I had some email technical difficulties
over the weekend. Comments inline.

On Tue, 2003-05-27 at 12:28, Paul Kyzivat wrote:
> Now that this draft is being publicly discussed, I will add these 
> comments to the discussion.
> 
> 	Paul
> 
> -------- Original Message --------
> Subject: Re: Draft Submission
> Date: Thu, 22 May 2003 21:02:39 -0400
> From: Paul Kyzivat <[email-masked]>
> To: Ben Campbell <[email-masked]>
> CC: [email-masked] <[email-masked]>,  Jon Peterson 
> <[email-masked]>, Robert Sparks <[email-masked]>, 
> Jonathan Rosenberg <[email-masked]>
> References: <[email-masked]>
> 
> Ben Campbell wrote:
>  > Please accept the attached as an Internet Draft submission. This draft
>  > is a work item of the SIMPLE work group.
> 
> This is looking really good. I can almost believe it is close to being
> baked!!!

Thanks!

> 
> I can't resist commenting to some extent:
> 
> 5.1) I'm uncomfortable with overloading the format list to describe both
> envelopes and contents. It then leads to hacks like the special casing
> of message/cpim as first entry in section 9.4.
> 
> Can't we just say that the formats listed in the m-line are only for top
> level types, which typically would only be message/cpim or maybe some
> other envelope type? Then define a new attribute in which to enumerate
> types that may be contained in the envelope. E.g.,
> 
>        m=message 49232 msrp/tcp message/cpim
>        a=content: text/plain text/html
> 

I don't have strong feelings on this. I was merely following practices I
have seen elsewhere for compound formats. If we were to separate
envelopes from content formats, I would tend to do the reverse; putting
leaf formats in the format list, and envelope specifications in an
attribute.

> 5.3) You say the address in the c-line and the port in the m-line are
> irrelevant. This isn't quite true. Minimally, a value of zero in the
> port field is relevant to rejecting the media stream altogether.
> 
> In addition, ignoring the c-line has a consequence that might be
> significant. It means there is no way to "blackhole" a media stream.
> There are interesting call flows where blackholing is important.
> 
> One possibility is to define a blackhole msrp url, such as
> msrp://0.0.0.0. The disadvantage of that is the node doing the
> blackholing needs to understand m=message is special in order to do it.
> In other cases it can be done naively without regard to media type. So
> another alternative would be to say we ignore the c-line as long as it
> isn't c=0.0.0.0. This is analogous to the hack for a zero port.

I think I prefer keeping the "0" semantics in the port field, and fixing
the wording.

> 
> 6.4) I found it very confusing that "credentials" and "challenge" aren't
> defined here, but are instead defined much later. In between, references
> are made to the non-terminals defined in that later part. I would prefer
> to see all the syntax in one place.

I see pros and cons either way. It probably makes sense to consolidate
all the abnf.

> 
> 6.5) I am trying to remember why we have imposed no ordering of
> messages, via TR-ID or otherwise. Ordering is a valuable thing for IM.
> 

Hmm. I would think the transport will enforce ordering, now that we have
no shared connections. Maybe we need to say something about relays
maintaining order.

> Also in this section you talk about timing out responses. But you don't
> ever say what should happen if a response arrives which fails to match
> any outstanding request. For timeouts to be useful, I guess late
> responses must be ignored, and that implies that bogus responses must
> also be ignored because they can't be distinguished.

OK

> 
> 6.6.1) In step 5 when an answerer is participating as a visitor, you say
> the c-line is copied unmodified from the offer to the answer. This seems
> unnecessary since the c-line is ignored in any case. And it can't always
> be done. If the c-line is global rather than local to the media stream,
> and there are multiple media streams, then it can't be copied.
> 

OK

> You also say the format list must be the same or a subset. You don't say
> if ordering must be preserved. Of course it doesn't matter if ordering
> is irrelevant. I think the only order specific behavior is * as last and
> message/cpim as first. But I wonder if order ought to express
> preference, as it does with codecs?

I order should express preference, which would imply maintaining order.

> 
> 6.6.3.1) you say "in SIP it *would* send a BYE...". This isn't the only
> alternative. (The media stream might be dropped by setting the port to
> zero.) So I think you need to say "in SIP it *could* send a BYE...".

Good point.

> 
> In next paragraph there are words missing: "This request MUST be sent
> [to the] host...".
> 
> 6.6.4) In first line, s/mention/mentioned/
> 
> 6.7.1) Item 1: you reference "the well-known port for MSRP relays" while
> earlier you say there is no default port.
> 
> The description of what an MSRP relay does also mentions its well-known
> port.

Oops.

> 
> Further, the description of BIND doesn't say anything about refreshing a
> BIND. It ought to be mentioned somewhere. One special behavior is
> probably required on refresh of bind: it must return the same session
> url as it did previously.
> 

Agreed,

> 6.7.4) Item 6: I'm thinking it would be good to permit the visiting
> relay to adjust the expiration time (down) before relaying it on.
> 

Hmm. I had been thinking about whether it could reduce the time on the
response, which clearly doesn't work. But I think your suggestion works.

> Then in item 7 there are some words missing: "Relay all subsequent [?]
> arriving...". I don't know if this should say "messages", "SEND and
> VISIT messages", or what.

I think I meant "messages." But on reflection that is probably
overbroard.

> 
> 6.9) in last paragraph you say sending a new request identical to the
> previous request. In addition to adding the CAuth header, doesn't the
> Tr-ID header need a new value?
> 

You are correct.

> 6.12.4) The def of nonce says: "This string SHOULD
> take the form of base64 or hexadecimal data". If it is base64 or hex
> then it needs to be decoded before being used in the MD5 algorithm. But
> there is nothing here to say how to tell base64 from hex from other.
> 

I had thought the operations would be on the encoded data, rather than
on decoded data.

> 7) The examples are using atlanta.com and biloxi.com. I thought there
> was a rule that examples all had to use *.example.com.
> 

RFC3261 uses atlanta.com, etc. But I can change it if we need to.

> 7.1) Item 2: missing a CR after "both"
> 
> Item 8: missing a CR before "Hi"
> 
> 9.3) s/encryption on for each/encryption for each/
> 
> -----
> 
> That's all I can find to note.
> 
> 	Look'n Good,
> 	Paul
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

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

---

From: Ben Campbell <[email-masked]>
Date: 28 May 2003 21:00:42 -0500

Thanks!

OK

OK

Good point.

Oops.

Agreed,

You are correct.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 May 2003 23:16:19 -0400

> leaf formats in the format list, and envelope specifications in an

I've had real problems with the ambiguity. Here it makes a difference, 
because unless you distinguish envelopes from contents there is no way 
to say the content must be within an envelope.

I don't know if there are reasons why we can't/shouldn't do this, but it 
seems like a good idea to me.

My reason for suggesting that the envelope be in the m-line is because 
in some sense that is all the MSRP protocol cares about. The leaves are 
of interest to whatever opens the envelope. But some discussion, and a 
beer, might convince me of the error in my thinking.

> I think I prefer keeping the "0" semantics in the port field, and fixing

That is only half of the issue. That means you can at least refuse an 
m=message media stream.

But that still leaves the separate issue of how to blackhole one. I 
think I prefer c=0.0.0.0 for that.

> no shared connections. Maybe we need to say something about relays

That may be sufficient now. But maybe we need to think more about 
ordering. I'm wondering what happens when we build an IM conference 
mixer. In that case order of arrival at the mixer may be a poor way of 
determining order.

But maybe this is a rathole right now.

> I order should express preference, which would imply maintaining order.

It makes sense. Just need to say something about it.

> I had thought the operations would be on the encoded data, rather than

I'm no crypto expert, but I would think that a bad thing. The nonce is 
supposed to introduce randomness. But if it always takes the form of a 
sequence of bytes that are all drawn from the characters used to 
represent hex or radix64 then the string is distinctly less random than 
it ideally should be. And if the only goal is to avoid conflicting with 
", then it would be simpler to just say the string can't include ".

It makes sense that this should encode a random bitstring, which would 
need to be encoded in hex or radix64 to be transmitted. But then it 
would need to be decoded before use, which requires that it be possible 
to figure out how to decode it. Radix64 can't always be distinguished 
from hex by inspection, since every hex string is a valid radix64 string.

> RFC3261 uses atlanta.com, etc. But I can change it if we need to.

I don't care, but I thought I had seen people whacked for not using 
example.com.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 May 2003 23:16:19 -0400

Paul