Re: [Dime] open issues #1 in DOIC

   Pseudo-session applications:

      While this class of application does not use the Diameter
      Session-ID AVP to correlate requests, there is an implied ordering
      of transactions defined by the application and except for the
      Session-ID differences pseudo-session based applications are
      generally assumed to behave like session-based application.  The
      3GPP defined Cx application [3GPP.29.229] is an example of a
      pseudo-session application.

Would this suffice?

- Jouni

On Nov 29, 2013, at 10:38 AM, lionel.morand@orange.com wrote:

> Hi,
> 
> For me, "pseudo-session" refers to session-based oriented applications that do not rely on the session-id for message correlations but on something else e.g. user-name. So it is implied that the same server is contacted by the client managing the session. In the Cx example, the same origin-host will be used in the client-initiated requests after the initial exchange and the server discovery phase.
> 
> Regards,
> 
> Lionel 
> 
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
> Envoyé : vendredi 29 novembre 2013 09:30
> À : dime@ietf.org list
> Objet : [Dime] open issues #1 in DOIC
> 
> Folks,
> 
>           [OpenIssue: Do we assume that all requests in a pseudo-session
>           typically need to go to the same server?]
> 
> 
> The example here is in context of Cx. Not that I am expert on Cx (or anything)
> but based on the CCF the requests _may_ have destination-host. Thus, I assume
> that it is an implementation issue whether pseudo-sessions need to go to the
> same server.. I guess we cannot have such firm requirement. Correct?
> 
> - Jouni
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 