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

["Arjun Roychowdhury" <[e-mail]>]

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