Skip to main content

Re: Updated EDR draft

  • From: "Lewis, Keith" < >
  • To: jsr359-experts < >
  • Subject: Re: Updated EDR draft
  • Date: Wed, 10 Apr 2013 14:58:42 +0100
  • List-id: <>

Some comments on EDR v03

Regarding section 13 I have sent a separate email.
Here are some of the significant points.

13.1 - why aren't we supporting the websocket client procedures?

13.2.3 - a browser may have several jsessionid cookies in progress at any one time for a server each with a different path corresponding to different web applications deployed on that server. The current text asserts that there is a single HttpSession "under which a client is operating". Either this statement is untrue and section 13.2.3 should be removed or the text should be expanded to explain it.

13.2.5 - The point I was trying to make in last weeks call is that it is dangerous to allow an application to close a flow which might still be required by other applications. Some containers might choose to provide an extension to allow this but we should not provide it in the standard API nor should we provide an equivalent capability for TCP connections as the note suggests.

Some comments on the outbound section

16.4 - perhaps the title should be changed to "Flow Selection" to make it clear that the container is providing support for Flows and not for the whole of RFC5626. Similarly the first paragraph could describe the API provided in terms of supporting flows. - perhaps the title should be "Decoding Flow Tokens".
The fact that the method returns a Flow object does not mean that the corresponding connection exists or that it currently has keepAlive running.

It may be better to call the method decodeFlow to make its functionality clear.

I still think it would be useful to be able to create a Flow object from a pair of URIs.

Flow SipFactory.createFlow(SipURI localURI, SipURI remoteURI); - we could remove the example code here and just describe the functionality offered. - it was useful to show the example to during our internal discussion but for the spec we could just use text to describe some examples of when getToken() and decodeFlow() might be used.


On Sat, Apr 6, 2013 at 7:15 PM, binod pg < " target="_blank"> > wrote:
Please find the updated EDR draft here.

- Added Outbound chapter.
- Updated with comments.
- Keith's latest e-mail on optionality is not yet handled.


Note: The information contained in this message may be privileged and confidential 
and protected from disclosure. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this message to the 
intended recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message and 
deleting it from your computer. Thank you. Thrupoint, Inc.

Updated EDR draft

binod pg 04/06/2013

Re: Updated EDR draft

Lewis, Keith 04/10/2013

Re: Updated EDR draft

binod pg 04/16/2013

Re: Updated EDR draft

Nitzan Nissim 04/17/2013

Nitzan's comments [Re: Updated EDR draft]

Binod 04/18/2013
Please Confirm