Gonzalo Camarillo | 2 Dec 00:58 2007
Picon

APPS review of the service identification draft

Hi,

you can find the APPS review of 
draft-ietf-sipping-service-identification-00.txt under the following link:

http://www1.ietf.org/mail-archive/web/apps-review/current/msg00112.html

Cheers,

Gonzalo

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Gonzalo Camarillo | 2 Dec 01:04 2007
Picon

SIP Interoperability Workshop - Materials Posted

FYI.

Gonzalo

--------
The submitted position papers for the First SIP Interoperability
Workshop can be found here:

<http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,4
2/Itemid,75>
Some mailers may break the above line.  Remember to reassemble it.
Otherwise, here is a TinyURL link to the same page.
http://tinyurl.com/2mq5cz

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Gonzalo Camarillo | 2 Dec 16:07 2007
Picon

Initial reviews of the Service Identification draft

Hi,

we have completed the initial review of the following draft:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-identification-00.txt

We have received the following four reviews. The author of the draft 
will be addressing these comments in a new revision of the
draft.
	http://www.softarmor.com/sipping/process/wg-review/reviews/draft-ietf-sipping-service-identification-00-mahesh.txt 
http://www.softarmor.com/sipping/process/wg-review/reviews/draft-ietf-sipping-service-identification-00-asveren.txt
http://www.softarmor.com/sipping/process/wg-review/reviews/draft-ietf-sipping-service-identification-00-dawkins.txt
http://www1.ietf.org/mail-archive/web/apps-review/current/msg00112.html

Cheers,

Gonzalo

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Cullen Jennings | 2 Dec 22:44 2007
Picon

Re: draft-elwell-sipping-update-pai-02


On Nov 30, 2007, at 12:15 AM, Elwell, John wrote:

> On the
> other hand, given that PAI is part of "core SIP", it would make some
> sense for it to be standards track.

Just to keep me on the right path here. When you say "core SIP", how  
would you define that?

Cullen <with my individual hat on>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

DRAGE, Keith (Keith | 2 Dec 22:54 2007

RE: draft-elwell-sipping-update-pai-02

I assume John is referring to its category in
draft-ietf-sip-hitchhikers-guide, rather than inventing the concept
himself.

Regards

Keith 

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy <at> cisco.com] 
> Sent: Sunday, December 02, 2007 9:45 PM
> To: Elwell, John
> Cc: sipping
> Subject: Re: [Sipping] draft-elwell-sipping-update-pai-02
> 
> 
> On Nov 30, 2007, at 12:15 AM, Elwell, John wrote:
> 
> > On the
> > other hand, given that PAI is part of "core SIP", it would 
> make some 
> > sense for it to be standards track.
> 
> 
> Just to keep me on the right path here. When you say "core 
> SIP", how would you define that?
> 
> Cullen <with my individual hat on>
> 
> 
(Continue reading)

Picon

Re: draft-elwell-sipping-update-pai-02

3325 is a core spec according to the hitchhikers guide criteria.

Jonathan R




 -----Original Message-----
From:   Cullen Jennings (fluffy)
Sent:   Sunday, December 02, 2007 04:46 PM Eastern Standard Time
To:     Elwell, John
Cc:     sipping
Subject:        Re: [Sipping] draft-elwell-sipping-update-pai-02


On Nov 30, 2007, at 12:15 AM, Elwell, John wrote:

> On the
> other hand, given that PAI is part of "core SIP", it would make some
> sense for it to be standards track.


Just to keep me on the right path here. When you say "core SIP", how 
would you define that?

Cullen <with my individual hat on>


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
nataraju.basavaraju | 3 Dec 05:35 2007

RE: Comments on draft - draft-ietf-sipping-sip-offeranswer-04.txt

The modifications looks fine with me.

Regards,
Nataraju A B

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com] 
> Sent: Friday, November 30, 2007 8:55 PM
> To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & 
> Carrier Infrastructure)
> Cc: tu-sawada <at> kddi.com; sipping <at> ietf.org
> Subject: Re: Comments on draft - 
> draft-ietf-sipping-sip-offeranswer-04.txt
> 
> 
> 
> nataraju.basavaraju <at> wipro.com wrote:
> >> "Note that an offer/answer exchange initiated by an INVITE 
> request  
> >> must follow exactly one of the patterns 1, 2, 3, 4.
> >>  <snip>
> >>  Pattern 2 and pattern 4 can occur only when the INVITE 
> request does  
> >> not include an offer. 'The first reliable non-failure 
> message' must  
> >> have an offer if there is no offer in the INVITE request. 
> This means  
> >> that UA which receives the INVITE request without an offer must  
> >> include an offer in the first reliable response with 100rel  
> >> extension. If no reliable provisional response has been 
> sent, the UAS  
> >> must include an offer when sending 2xx response."
> >>
> > 
> > The complete paragraph makes sense, but I still think 1st sentence 
> > does confuse. Particularly the word ***AND*** confuses even though 
> > subsequent sentences makes the complete logic clear.
> > I was thinking changing the phrase from "Pattern 2 AND 
> pattern 4" to 
> > "Pattern 2 OR pattern 4" makes it clear enough.
> > 
> > If I am still confusing you, you can ignore this comment since the 
> > complete paragraph makes it clear about delayed O/A.
> 
> I get your point but the paragraph seems a little awkward to 
> me that way. What about:
> 
>     Note that an offer/answer exchange initiated by an INVITE request
>     must follow exactly one of the patterns 1, 2, 3, 4. When 
> an initial
>     INVITE causes multiple dialogs due to forking, an offer/answer
>     exchange is carried out independently in each distinct dialog.
>     When an INVITE request contains no offer, only pattern 2 or
>     pattern 4 apply. 'The first reliable non-failure message' must
>     have an offer if there is no offer in the INVITE request. 
> This means
>     that UA which receives the INVITE request without an offer must
>     include an offer in the first reliable response with 100rel
>     extension. If no reliable provisional response has been 
> sent, the UAS
>     must include an offer when sending 2xx response.
> 
> This only changes the ordering of the words, but it makes it 
> more consistent with the earlier part of the paragraph and 
> seems slightly clearer to me.
> 
[ABN] This looks fine with me... At least no confusion...:)

> 	Paul
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Takuya Sawada | 3 Dec 05:47 2007

Re: Comments on draft - draft-ietf-sipping-sip-offeranswer-04.txt

Looks fine with me, too.
Thanks, Paul.

Regards,
Takuya

> 
> The modifications looks fine with me.
> 
> Regards,
> Nataraju A B
>  
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com] 
> > Sent: Friday, November 30, 2007 8:55 PM
> > To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & 
> > Carrier Infrastructure)
> > Cc: tu-sawada <at> kddi.com; sipping <at> ietf.org
> > Subject: Re: Comments on draft - 
> > draft-ietf-sipping-sip-offeranswer-04.txt
> > 
> > 
> > 
> > nataraju.basavaraju <at> wipro.com wrote:
> > >> "Note that an offer/answer exchange initiated by an INVITE 
> > request  
> > >> must follow exactly one of the patterns 1, 2, 3, 4.
> > >>  <snip>
> > >>  Pattern 2 and pattern 4 can occur only when the INVITE 
> > request does  
> > >> not include an offer. 'The first reliable non-failure 
> > message' must  
> > >> have an offer if there is no offer in the INVITE request. 
> > This means  
> > >> that UA which receives the INVITE request without an offer must  
> > >> include an offer in the first reliable response with 100rel  
> > >> extension. If no reliable provisional response has been 
> > sent, the UAS  
> > >> must include an offer when sending 2xx response."
> > >>
> > > 
> > > The complete paragraph makes sense, but I still think 1st sentence 
> > > does confuse. Particularly the word ***AND*** confuses even though 
> > > subsequent sentences makes the complete logic clear.
> > > I was thinking changing the phrase from "Pattern 2 AND 
> > pattern 4" to 
> > > "Pattern 2 OR pattern 4" makes it clear enough.
> > > 
> > > If I am still confusing you, you can ignore this comment since the 
> > > complete paragraph makes it clear about delayed O/A.
> > 
> > I get your point but the paragraph seems a little awkward to 
> > me that way. What about:
> > 
> >     Note that an offer/answer exchange initiated by an INVITE request
> >     must follow exactly one of the patterns 1, 2, 3, 4. When 
> > an initial
> >     INVITE causes multiple dialogs due to forking, an offer/answer
> >     exchange is carried out independently in each distinct dialog.
> >     When an INVITE request contains no offer, only pattern 2 or
> >     pattern 4 apply. 'The first reliable non-failure message' must
> >     have an offer if there is no offer in the INVITE request. 
> > This means
> >     that UA which receives the INVITE request without an offer must
> >     include an offer in the first reliable response with 100rel
> >     extension. If no reliable provisional response has been 
> > sent, the UAS
> >     must include an offer when sending 2xx response.
> > 
> > This only changes the ordering of the words, but it makes it 
> > more consistent with the earlier part of the paragraph and 
> > seems slightly clearer to me.
> > 
> [ABN] This looks fine with me... At least no confusion...:)
> 
> > 	Paul
> > 
> 
> 
> The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 
> 
> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any
attachments for the presence of viruses. The company accepts no liability for any damage caused by any
virus transmitted by this email.
>  
> www.wipro.com

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
tu-sawada <at> kddi.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Elwell, John | 3 Dec 05:59 2007
Picon

RE: FW: NewVersionNotificationfordraft-petrie-sipping-voip-features-dataset-02

Christer,

I read 2.3 of voip-featurs-dataset as being concerned only with the
configuration of call waiting.

John 

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg <at> ericsson.com] 
> Sent: 30 November 2007 09:21
> To: Elwell, John; Mary Barnes; Ganesan Sam-W00184; 
> sipping <at> ietf.org; shida <at> ntt-at.com; Jason Fischl
> Subject: RE: [Sipping] FW: 
> NewVersionNotificationfordraft-petrie-sipping-voip-features-dataset-02
> 
> 
> Hi,
> 
> My concern is not related to the configuration parts.
> 
> But, chapter 2.3 is more than configuration - it is Call 
> Waiting feature
> definition.
> 
> Regards,
> 
> Christer
> 
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:john.elwell <at> siemens.com] 
> > Sent: 30. marraskuuta 2007 10:24
> > To: Mary Barnes; Christer Holmberg; Ganesan Sam-W00184; 
> > sipping <at> ietf.org; shida <at> ntt-at.com; Jason Fischl
> > Subject: RE: [Sipping] FW: New 
> > VersionNotificationfordraft-petrie-sipping-voip-features-dataset-02
> > 
> > Christer,
> > 
> > Just an addition to what Mary says. Although in the context 
> > of the automatic call handling (ACH) topic in BLISS, one of 
> > the concerns identified is to do with configuration, if this 
> > were to lead to protocol work it would not necessarily be 
> > done in BLISS. In fact, if it requires enhancement to the 
> > config framework and its profile datasets, then I would 
> > expect BLISS to ask SIPPING to do that work.
> > 
> > John
> > 
> > > -----Original Message-----
> > > From: Mary Barnes [mailto:mary.barnes <at> nortel.com]
> > > Sent: 30 November 2007 00:18
> > > To: Christer Holmberg; Ganesan Sam-W00184; sipping <at> ietf.org
> > > Subject: RE: [Sipping] FW: New Version
> > > Notificationfordraft-petrie-sipping-voip-features-dataset-02
> > > 
> > > Christer,
> > > 
> > > I would agree for the services that BLISS is chartered to 
> describe, 
> > > this document should be consistent. However, you have to 
> > keep in mind 
> > > that the work in this area significantly pre-dates the 
> > BLISS WG. And, 
> > > BLISS isn't the only other work area to consider. For 
> example, the 
> > > Emergency section needs to consider the work in ECRIT and likely 
> > > reference phone-bcp.  So, yes, there is some major reworking that 
> > > needs to happen with this particular document.
> > > 
> > > The most important document of the "petrie-sipping-*-dataset" 
> > > series set
> > > is draft-petrie-sipping-profile-datasets-05.txt, which 
> defines the 
> > > general approach for profile data. That document is a 
> > dependency for 
> > > the policy work in SIP and SIPPING WGs.  So, feedback on that 
> > > particular document (detailed and general readiness to 
> > progress as a 
> > > Working Group
> > > item) would be especially appreciated.
> > > 
> > > Thanks,
> > > Mary. 
> > > 
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:christer.holmberg <at> ericsson.com]
> > > Sent: Wednesday, November 21, 2007 4:58 AM
> > > To: Ganesan Sam-W00184; sipping <at> ietf.org
> > > Subject: RE: [Sipping] FW: New Version Notification
> > > fordraft-petrie-sipping-voip-features-dataset-02
> > > 
> > > 
> > > Isn't this partly overlapping with the BLISS work?
> > > 
> > > Regards,
> > > 
> > > Christer
> > > 
> > > > -----Original Message-----
> > > > From: Ganesan Sam-W00184 [mailto:sam.ganesan <at> motorola.com]
> > > > Sent: 20. marraskuuta 2007 15:01
> > > > To: sipping <at> ietf.org
> > > > Subject: [Sipping] FW: New Version Notification
> > > > fordraft-petrie-sipping-voip-features-dataset-02
> > > > 
> > > >  
> > > > 
> > > > -----Original Message-----
> > > > From: IETF I-D Submission Tool [mailto:idsubmission <at> ietf.org]
> > > > Sent: Sunday, November 18, 2007 5:50 PM
> > > > To: Ganesan Sam-W00184
> > > > Cc: dan.ietf <at> SIPez.com; sumanth <at> cablelabs.com
> > > > Subject: New Version Notification for
> > > > draft-petrie-sipping-voip-features-dataset-02
> > > > 
> > > > 
> > > > A new version of I-D,
> > > > draft-petrie-sipping-voip-features-dataset-02.txt
> > > > has been successfuly submitted by Sam Ganesan and posted to
> > > the IETF
> > > > repository.
> > > > 
> > > > Filename:	 draft-petrie-sipping-voip-features-dataset
> > > > Revision:	 02
> > > > Title:		 The Session Initiation Protocol User Agent VoIP
> > > > Features Data Set
> > > > Creation_date:	 2007-11-17
> > > > WG ID:		 Independent Submission
> > > > Number_of_pages: 13
> > > > 
> > > > Abstract:
> > > > This document defines the properties and format for the SIP
> > > user agent
> > > 
> > > > VoIP Features data set.  The properties defined in this
> > > document are
> > > > expected to be common to most SIP user agents that provide VoIP 
> > > > capabilities.  These VoIP Feature properties are 
> > considered to be a 
> > > > data set.  Several types of datasets may be combined into 
> > documents 
> > > > that are provided to SIP user agents so that they can
> > > operate with the
> > > 
> > > > desired behavior.
> > > >  
> > > > 
> > > > 
> > > > 
> > > > The IETF Secretariat.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP Use 
> > > > sip-implementors <at> cs.columbia.edu for questions on 
> current sip Use 
> > > > sip <at> ietf.org for new developments of core SIP
> > > > 
> > > 
> > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP Use 
> > > sip-implementors <at> cs.columbia.edu for questions on current sip Use 
> > > sip <at> ietf.org for new developments of core SIP
> > > 
> > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP Use 
> > > sip-implementors <at> cs.columbia.edu for questions on current sip Use 
> > > sip <at> ietf.org for new developments of core SIP
> > > 
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP 
> > Use sip-implementors <at> cs.columbia.edu for questions on current 
> > sip Use sip <at> ietf.org for new developments of core SIP
> > 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Cullen Jennings | 3 Dec 06:39 2007
Picon

Re: draft-elwell-sipping-update-pai-02


Ok, I just went and read hitchhiker again and saw it defines

    Core:  The essential SIP specifications that are expected to be
       utilized for every session or registration.

well I find this really scary in the same way that I find sipping-16  
scary. If we view that we are going to start seeing RFP that ask for  
all of "core SIP" as defined in hitchhikers, then this document is  
getting very much the wrong level of review and would probably would  
better be a BCP. I was under the impression these were more arranged  
in a way of just grouping into logical categories to help find them  
without making a value judgement about what RFC were needed and what  
was not.

On Dec 2, 2007, at 3:54 PM, Jonathan Rosenberg (jdrosen) wrote:

> 3325 is a core spec according to the hitchhikers guide criteria.
>
> Jonathan R
>
>
>
>
>  -----Original Message-----
> From:   Cullen Jennings (fluffy)
> Sent:   Sunday, December 02, 2007 04:46 PM Eastern Standard Time
> To:     Elwell, John
> Cc:     sipping
> Subject:        Re: [Sipping] draft-elwell-sipping-update-pai-02
>
>
> On Nov 30, 2007, at 12:15 AM, Elwell, John wrote:
>
> > On the
> > other hand, given that PAI is part of "core SIP", it would make some
> > sense for it to be standards track.
>
>
> Just to keep me on the right path here. When you say "core SIP", how
> would you define that?
>
> Cullen <with my individual hat on>
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org for new developments of core SIP
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP


Gmane