Subject: RE: [SIP] The NOTIFY method

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 9 Aug 2000 16:21:52 -0400

Yep, that was one of those "Informational RFCs" I was talking about.

Brian

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2000 4:19 PM
> To: Rosen, Brian
> Cc: 'Tom Gray'; Henry Sinnreich; Robert Sparks; 
> [email-masked]
> Subject: Re: [SIP] The NOTIFY method
> 
> 
> Brian,
> 
> The next call flows document, SIP Service Examples (based on what was
> section 7 from draft-ietf-sip-call-flows-00.txt which uses 
> Bye-Also) will
> cover many of these issues, and will hopefully become an Informational
> RFC.   The basic goal of the document will be to give 
> examples of common
> PSTN Class and PBX features using SIP.  The draft will use 
> REFER and other
> new methods and extensions.
> 
> Alan.
> 
> "Rosen, Brian" wrote:
> 
> > My opinion is that where it is essential that two sip components
> > agree on how a feature is to be handled, then there should be
> > some kind of document that describes how that works, so that
> > interoperability can be achieved.  If the feature is solely 
> implemented
> > in a single element, then it is not something we need to
> > worry about.
> >
> > Just because there needs to be a document does not imply a standards
> > track RFC.  Only things which are not achievable with existing SIP
> > methods might need extensions.  Other features might be covered in
> > other kinds of documents, Informational RFCs for example, or even
> > documents not in the IETF.
> >
> > > -----Original Message-----
> > > From: Tom Gray [mailto:[email-masked]]
> > > Sent: Monday, August 07, 2000 6:49 PM
> > > To: Henry Sinnreich; Robert Sparks; [email-masked]
> > > Subject: RE: [SIP] The NOTIFY method
> > >
> > >
> > >
> > > --- Henry Sinnreich <[email-masked]> wrote:
> > > > >May I ask why SIP is being extended to include PBX
> > > > >feature handling?
> > > >
> > > > SIP phones can provide the PBX features without the
> > > > (IP)PBX.
> > > >
> > > > Henry
> > > >
> > >
> > > What levels of features do you then see being created
> > > with SIP?  There a a whole host of PBX features. It
> > > seems that you are asking for a subset.
> > >
> > > Tom Gray
> > >
> > >
> > >
> >
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Tom Gray <[email-masked]>
Date: Thu, 10 Aug 2000 06:16:00 -0700 (PDT)

> Yep, that was one of those "Informational RFCs" I

The informaional RFC is described as being concerned
with 'interoperability.' I assume that RFCs like this
will only be illustrative as to how these extensions
could be used to create different feature types. I do
not see it to be beneficial to the user or vendor for
the IETF to attempt to decide on the details of
feature operation and interaction.

Tom Gray

> > > > seems that you are asking for a subset.

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 10 Aug 2000 09:37:55 -0400

Well, Informational means Informational, and not Standard,
so you get what you asked for.

As the saying goes, we aren't the protocol police, so any
RFC we create can be violated with impunity. Of course, as a customer, 
I could always demand compliance to an Informational RFC if I wanted to.

Many of the examples show how features COULD be implemented,
but there are other ways to do them.  I worry some about 
features that require both a UA and a proxy server to agree on
how they are implemented, because I want a Brand X UA to work with
a Brand Y proxy server.  For that matter if it depends on two UAs
or two proxy servers, I want to mix and match them too.
However, at this time, I would not advocate trying to create a 
standards track RFC that defines how such features work.

In some cases, as with Transfer, a new method is needed.  The draft
addresses that need for Transfer, and I think it should be moved 
along to a standards track RFC.

Brian

> Sent: Thursday, August 10, 2000 9:16 AM
> To: Rosen, Brian; 'Alan Johnston'