RE: [Sipping] FW: I-D ACTION:draft-donovan-sipping-service-override-01.txt

["Steve Donovan \(stdonova\)" <[e-mail]>]

The expectation is that the guidelines for use of this header would be
done elsewhere.  This could be in the IETF, in another standards body,
in a joint agreement between vendors or elsewhere.  

The piece being standardized here is the mechanism to communicate the
results of application invocation from the AS to the SM.  The structure
of the header, being just a token, does leave the format pretty free
form.  It might be interesting to discuss if it would be helpful to puts
some structure to the state token.  However, this still leaves the
definition of the actual values of the token outside of the scope of
this document.

Do you have suggestions on the structure of the state token?

Steve 

> -----Original Message-----
> From: Arjun Roychowdhury [mailto:[e-mail]] 
> Sent: Wednesday, July 05, 2006 11:41 AM
> To: Steve Donovan (stdonova)
> Cc: sipping
> Subject: Re: [Sipping] FW: I-D 
> ACTION:draft-donovan-sipping-service-override-01.txt
> 
> Steve, thanks for the clarification. However, it looks like 
> left at this level, an xSM will only work with an xAS and not 
> yAS (that is, it is not possible for the SM and AS to be 
> provided by different vendors), since this draft does not 
> publish common guidelines that can be followed.
> 
> Is this assumption correct ? If so, I am still a little 
> concerned on the requirement for this header, since it will  
> be of proprietary use, and  hence the SM and the AS can 
> define any mechanism (an INFO message, a header etc.) to 
> communicate the state and that should not need a standardization.
> 
> regds
> arjun
> 
> 
> On 7/5/06, Steve Donovan (stdonova) <[e-mail]> wrote:
> > Arjun,
> >
> > The draft intentionally leaves the definition of the syntax and 
> > meaning of the state undefined.  This is something that is 
> significant 
> > only in the relationship between the "requesting" SM and the AS 
> > handing the request.
> >
> > The goal of this draft is to formalize a mechanism for an AS to 
> > communicate the results of application handling back to the 
> SM.  Note 
> > that as defined, the SM then strips the Service-State 
> header from the 
> > request, so subsequent AS, SM or UA instances would not see 
> the header.
> >
> > The definition of standardized values and any associated 
> semantics for 
> > the token(s) carried in the Service-State header, if needed, is a 
> > separate question that is best done in the context of 
> specific service 
> > related use cases.
> >
> > This definition is not needed for the mechanism described in this 
> > draft to be useful, as all that is needed is agreement 
> between the SM 
> > and AS instances on the syntax and semantics of the 
> Service-State header.
> >
> > I hope this helps...
> >
> > Steve
> >
> > > -----Original Message-----
> > > From: Arjun Roychowdhury [mailto:[e-mail]]
> > > Sent: Friday, June 30, 2006 11:59 AM
> > > To: Steve Donovan (stdonova)
> > > Cc: sipping
> > > Subject: Re: [Sipping] FW: I-D
> > > ACTION:draft-donovan-sipping-service-override-01.txt
> > >
> > > Hi,
> > > This document does not describe how to populate the 
> Service-State, 
> > > what really is 'state' and how does one ensure that it is 
> understood 
> > > by the xAS, xSM and xUA.
> > >
> > > I would like to hear the author's opininon on what really is this 
> > > State. Unless it is defined, I don't see how it is 
> beneficial over 
> > > any proprietary tag.  Judging by the current discussion about the 
> > > IMS CSI, it looks like the term 'service' is found to be too 
> > > restrictive in this group, and it is preferred to leave it as 
> > > 'primitives', in which case, I am curious how a service 
> state can be 
> > > defined (and even if defined, what use would it be, if service 
> > > cannot be defined).
> > >
> > > regds
> > > arjun
> > >
> > >
> > > regds
> > > arjun
> > >
> > >
> > >
> > > On 6/30/06, Steve Donovan (stdonova) <[e-mail]> wrote:
> > > > All,
> > > >
> > > > Please find the attached reference to a draft for
> > > consideration by the
> > > > SIPPING working group.
> > > >
> > > > Comments are welcome and solicited.
> > > >
> > > > Regards,
> > > >
> > > > Steve Donovan
> > > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]]
> > > > Sent: Thursday, June 29, 2006 2:50 PM
> > > > To: [e-mail]
> > > > Subject: I-D 
> ACTION:draft-donovan-sipping-service-override-01.txt
> > > >
> > > > A New Internet-Draft is available from the on-line 
> Internet-Drafts 
> > > > directories.
> > > >
> > > >
> > > >        Title           : The Service-State Header
> > > >        Author(s)       : C. Sivachelvan, S. Donovan
> > > >        Filename        :
> > > draft-donovan-sipping-service-override-01.txt
> > > >        Pages           : 21
> > > >        Date            : 2006-6-29
> > > >
> > > > This document proposes a new header for the Session Initiation
> > > >   Protocol.  This header, the Service-State header, is used to
> > > >   communicate application state between two SIP elements.
> > > >
> > > >   Note: The name of the file will be updated to be
> > > consistent with the
> > > >   proposed header name in the next revision of the draft.
> > > >
> > > > A URL for this Internet-Draft is:
> > > >
> > > 
> http://www.ietf.org/internet-drafts/draft-donovan-sipping-service-ov
> > > er
> > > > ri
> > > > de-01.txt
> > > >
> > > > To remove yourself from the I-D Announcement list, send a
> > > message to
> > > > [e-mail] with the word unsubscribe in
> > > the body of
> > > > the message.
> > > > You can also visit
> > > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > > to change your subscription settings.
> > > >
> > > >
> > > > Internet-Drafts are also available by anonymous FTP. Login with 
> > > > the username "anonymous" and a password of your e-mail address. 
> > > > After logging in, type "cd internet-drafts" and then
> > > >        "get draft-donovan-sipping-service-override-01.txt".
> > > >
> > > > A list of Internet-Drafts directories can be found in 
> > > > http://www.ietf.org/shadow.html or 
> > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > > >
> > > > Internet-Drafts can also be obtained by e-mail.
> > > >
> > > > Send a message to:
> > > >        [e-mail].
> > > > In the body type:
> > > >        "FILE
> > > > /internet-drafts/draft-donovan-sipping-service-override-01.txt".
> > > >
> > > > NOTE:   The mail server at ietf.org can return the document in
> > > >        MIME-encoded form by using the "mpack" utility.  
> To use this
> > > >        feature, insert the command "ENCODING mime" 
> before the "FILE"
> > > >        command.  To decode the response(s), you will need
> > > "munpack" or
> > > >        a MIME-compliant mail reader.  Different MIME-compliant 
> > > > mail readers
> > > >        exhibit different behavior, especially when dealing with
> > > >        "multipart" MIME messages (i.e. documents which have
> > > been split
> > > >        up into multiple messages), so check your local
> > > documentation on
> > > >        how to manipulate these messages.
> > > >
> > > >
> > > > Below is the data which will enable a MIME compliant 
> mail reader 
> > > > implementation to automatically retrieve the ASCII 
> version of the 
> > > > Internet-Draft.
> > > >
> > > >
> > > > _______________________________________________
> > > > Sipping mailing list  
> > > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP Use 
> > > > [e-mail] for questions on 
> current sip Use 
> > > > [e-mail] for new developments of core SIP
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Arjun Roychowdhury
> > >
> >
> 
> 
> --
> Arjun Roychowdhury
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP