Subject: RE: [Simple] Comments on message-sessions-02

From: [email-masked]
Date: Mon, 10 Nov 2003 22:53:57 +0200

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: Friday, November 07, 2003 7:16 PM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] Comments on message-sessions-02
> 
> 
> Hi--I addressed some points in separate emails. Others inline:
> 
> [email-masked] wrote:
> 
> [...]
> 
> > - Section 4: 
[snip]
> 
> >    - This section also talks about inactivity timer, and 
> says that that hosting device invalidates the session state 
> when timer expires. Why is it just the hosting device?
> 
> Let me turn that question around. Why would any other device need to? 
> When the hosting device closes the session, the endpoints 
> will learn of 
> it in short order as they get their connections closed. So will a 
> visiting relay, for that matter (although I do think we have an open 
> item on whether visiting relays should have to worry about the timer.)

Why does the visiting peer have an inactivity timer then? It also needs to clear up state on its end when the timer fires.

> 
> > 
> > - Section 5.1:
> >    - Is this section normative? It have normative text like 
> SHOULD and SHOULD not.
> 
> Yes, section 5.1 is intended to be normative, although it contains no 
> statements stronger than SHOULD. But we mean those SHOULDs 
> just as much 
> as any other SHOULDs in the document. :-)

maybe those SHOULDs and SHOULD NOTs should be changed to lower case :)

> 
> > 
> > - Section 5.2:
> >    - Open issue: the attribute accept-type can be used to 
> restrict the use of a message session. So if a session was 
> created to send mpeg video. The accept-types attribute should 
> only carry that mime-type. In this way, the other endpoint 
> does not use that session to send normal messages.
> 
> That is an interesting approach. But I think we may have overlap in 
> types that are allowed on an IM session, and types that are 
> allowed on a 
> file transfer session. What if I want to transfer a large 
> file of type 
> text/plain?

Excuse my ignorance, but don't files have their own mime-type text/something?

[snip]
> 
> > 
> > - Section 6.1:
> >    - The example is missing the accept-types attribute.
> 
> The example in 6.1 is explicitly just an m-line, not an 
> entire SDP document.

But the text above the example indicates that the example shows the accept types.

> 
> > 
> > - Section 6.3:
> >   - the BNF provided allows accept-types to have multiple 
> *. eg: a=accept-types: * * *
> >     It should be fixed to something like: 
> > 
> >                accept-types       = accept-types-label ":" 
> format-list
> >                accept-types-label = "accept-types"
> >                format-list        = "*" / format-entries
> >                format-entries     = format-entry *( SP format-entry)
> >                format-entry       = (type "/" subtype)
> >                type               = token
> >                subtype            = token
> > 
> 
> That does not seem to allow for something like "a=accept-types: 
> message/cpim text/plain *", which is semantically meaningful. I can 
> change the syntax to only allow one "*", but do we really 
> care? "* * *" 
> may be silly, but it can still be interpreted reasonably.

what does it mean to say "a=accept-types: message/cpim text/plain *" ? * is enough in this case and encapsulates  message/cpim and text/plain.

> 
> [...]
> 
> > - Section 7.1.2:
> >    - Why is there text describing the use of SRV if no port 
> is present? The port is mandatory and therefore resolving 
> should fail if no port is present. INVITE requests would then 
> be rejected. If we want SRV, then we need to relax the MUST for port.
> > 
> 
> It is not mandatory for a URL that designates a relay that is 
> handed to 
> an endpoint out-of-band. (For example, when a user configures 
> a client 
> to use a relay.)

Section 7.1 says: 

"An MSRP URL server part identifies the hosting device of an MSRP
   session. If the server part contains a numeric IP address, it MUST
   also contain a port"

So maybe you need to add text differentiating between a relay URL and a session URL.

/Hisham 

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Nov 2003 15:02:56 -0600

> Why does the visiting peer have an inactivity timer then? It also needs to clear up state on its end when the timer fires.

It needs it so that it knows when and if it needs to send traffic to 
avoid having the host device kill the session.

> maybe those SHOULDs and SHOULD NOTs should be changed to lower case :)

I am not sure of the point. You are suggesting they should not be 
normative? Why?

> Excuse my ignorance, but don't files have their own mime-type text/something?

It may be my own ignorance speaking, but I would expect a text file to 
have a mime type of text/plain. Which is also a reasonable type for an IM.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Nov 2003 15:02:56 -0600