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

From: [email-masked]
Date: Tue, 11 Nov 2003 05:05:41 +0200

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: Monday, November 10, 2003 11:03 PM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] Comments on message-sessions-02
> 
> 
> [email-masked] wrote:
> 
> > 
> >>-----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.
> > 
> 
> It needs it so that it knows when and if it needs to send traffic to 
> avoid having the host device kill the session.

well, that was my point. The text in that specific section omits this information about the visitor.

> 
> > 
> >>>- 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 :)
> > 
> 
> I am not sure of the point. You are suggesting they should not be 
> normative? Why?

I think this whole section 5.1 is just informative. EG: "Therefore relays SHOULD NOT be used indiscriminately", how is that a protocol normative text?

> 
> > 
> >>>- 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?
> > 
> 
> 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.

text/plain does not tell you there is a file attached. I believe it has its own mime type.

> >>
> >>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.

Does your silence on this issue means you agree?

> > 
> > 
> >>[...]
> >>
> >>
> >>>- 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.

Also here??

/Hisham

> > /Hisham 

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Nov 2003 21:32:12 -0600

> well, that was my point. The text in that specific section omits this information about the visitor.

OK, if the point is that the text needs clarification, then I can buy it.

> I think this whole section 5.1 is just informative. EG: "Therefore relays SHOULD NOT be used indiscriminately", how is that a protocol normative text?

We have had normative text in "usage guidlines" in the past. I agree it 
is rather odd. I am not opposed to treating it as informative, but will 
not be surprised if others are.

> text/plain does not tell you there is a file attached. I believe it has its own mime type.

Anyone else want to comment on this? I am pretty sure you can have a 
text/plain file--but I will go do some research to make sure I have not 
gone insane.

> Does your silence on this issue means you agree?

No, it means I did not scroll down far enough. "message/cpim text/plain 
*" is explicitly described to mean that you can attempt any format, but 
you should prefer message/cpim or text/plain.

>>relay URL and a session URL.

Also a scrolling error.

It's are the same kind of URL. There is text that says that the port 
must be included if delivered in an sdp offer/answer. There is no such 
text for other usages.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Nov 2003 21:32:12 -0600

Also a scrolling error.