gao.yang2 | 1 Mar 06:44 2010
Picon

Re: Hi Paul //About draft-ietf-sipping-sip-offeranswer-11


As you have a new version, I think including sipping would be better :)

Thanks for your agreement at this point.

But as RFC3261's words of "willings" is not as clear as guidance for system design and implement, I think some BCP level description vcould be better.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2 <at> zte.com.cn
===================================


Paul Kyzivat <pkyzivat <at> cisco.com>

2010-02-26 22:17

收件人
gao.yang2 <at> zte.com.cn
抄送
sipping <sipping <at> ietf.org>
主题
Re: Hi Paul  //About draft-ietf-sipping-sip-offeranswer-11







gao.yang2 <at> zte.com.cn wrote:
>
> I just find a potential problem of
> draft-ietf-sipping-sip-offeranswer-11. I am not sure will you want have
> a new version, so I send this discussion offline.

I am working on another version. I am including sipping in my response
so others have the opportunity to comment. (I trust that is ok.)

> Section 5.2.5. of draft-ietf-sipping-sip-offeranswer-11:
> When the new offer is sent in response to an offerless (re)INVITE,
>    *all codecs supported by the UA are to be included*, not just the ones
>    that were negotiated by previous offer/answer exchanges.  *The same is*
> *   true for media types* - so if UA A initially offered audio and video
>    to UA B, and they end up with only audio, and UA B sends an offerless
>    (re)INVITE to UA A, A's resulting offer should re- attempt video, by
>    reusing the zeroed m-line used previously.
>
>
> While Re-INVITE without Offer:
> For codecs, I think the UAS should include as many codecs that the UA is
> willing(section 14.2 of RFC3261) to support. I think we should let the
> UA has the right to decide which codecs can be use or not for this
> current call. At the same time, the UAS should be with responsibility
> for failure of session if it cut down the number of codecs. UAS's
> willing of codecs can be implemented as local policy or some other forms
> of configuration.

Yes, this just requires minor tweak to wording.
Its consistent with the recommendations on sendonly/...

> For media types, it is almost the same as codecs, about UA's willing.
> But I think we should emphasize on avoiding of introducing new media
> types without user's permission, such as just introducing new media
> types  by equipment or software. Beacause I have met such charging
> arguement from users in some operating telecom-network.(If you want the
> detail of the charging arguement, I'd like to share it with you).
> So, if there is no indication of permission of introducing new media
> types from the end user, UAS should just include current using media
> types. And if the other side(user of UAC) want to add media types, it
> can using another new Offer.

I get your point and agree. Its the same concept - include everything
the UA would be willing to use, not just that which it thinks the peer
wants to use.

                Thanks,
                Paul

> Thanks,
>
> Gao
>
> Section 14.2 of RFC3261:
> A UAS providing an offer in a 2xx (because the INVITE did not contain
>    an offer) SHOULD construct the offer as if the UAS were making a
>    brand new call, subject to the constraints of sending an offer that
>    updates an existing session, as described in [13] in the case of SDP.
>    Specifically, this means that it SHOULD include as many media formats
>    and media types that the UA *is willing to support*.  The UAS MUST
>    ensure that the session description overlaps with its previous
>    session description in media formats, transports, or other parameters
>    that require support from the peer.  This is to avoid the need for
>    the peer to reject the session description.  
>
> ===================================
> Zip    : 210012
> Tel    : 87211
> Tel2   :(+86)-025-52877211
> e_mail : gao.yang2 <at> zte.com.cn
> ===================================
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>



-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
Sipping mailing list  https://www.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
Internet-Drafts | 2 Mar 04:15 2010
Picon

I-D Action:draft-ietf-sipping-policy-package-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title           : A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies.
	Author(s)       : V. Hilt, G. Camarillo
	Filename        : draft-ietf-sipping-policy-package-06.txt
	Pages           : 18
	Date            : 2010-03-01

This specification defines a Session Initiation Protocol (SIP) event
package for session-specific policies.  This event package enables
user agents to subscribe to session policies for a SIP session and to
receive notifications if these policies change.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy-package-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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://www.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
gao.yang2 | 2 Mar 08:01 2010
Picon

Re: Hi Paul //About draft-ietf-sipping-sip-offeranswer-11


Hi Paul,

I just feel adding some BCP level description (something like the description below) would let people do system design and implement clearly.

"When recv Re-INVITE without Offer, UAS SHOULD avoid of introducing new media types without user's permission or local policy configuration, that is its current using media types."

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2 <at> zte.com.cn
===================================
----- 转发人 GaoYang140197/user/zte_ltd 时间 2010-03-02 14:56 -----
GaoYang140197/user/zte_ltd

2010-03-01 13:44

收件人
Paul Kyzivat <pkyzivat <at> cisco.com>
抄送
sipping <sipping <at> ietf.org>
主题
Re: Hi Paul  //About draft-ietf-sipping-sip-offeranswer-11链接





As you have a new version, I think including sipping would be better :)

Thanks for your agreement at this point.

But as RFC3261's words of "willings" is not as clear as guidance for system design and implement, I think some BCP level description vcould be better.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2 <at> zte.com.cn
===================================


Paul Kyzivat <pkyzivat <at> cisco.com>

2010-02-26 22:17

收件人
gao.yang2 <at> zte.com.cn
抄送
sipping <sipping <at> ietf.org>
主题
Re: Hi Paul  //About draft-ietf-sipping-sip-offeranswer-11







gao.yang2 <at> zte.com.cn wrote:
>
> I just find a potential problem of
> draft-ietf-sipping-sip-offeranswer-11. I am not sure will you want have
> a new version, so I send this discussion offline.

I am working on another version. I am including sipping in my response
so others have the opportunity to comment. (I trust that is ok.)

> Section 5.2.5. of draft-ietf-sipping-sip-offeranswer-11:
> When the new offer is sent in response to an offerless (re)INVITE,
>    *all codecs supported by the UA are to be included*, not just the ones
>    that were negotiated by previous offer/answer exchanges.  *The same is*
> *   true for media types* - so if UA A initially offered audio and video
>    to UA B, and they end up with only audio, and UA B sends an offerless
>    (re)INVITE to UA A, A's resulting offer should re- attempt video, by
>    reusing the zeroed m-line used previously.
>
>
> While Re-INVITE without Offer:
> For codecs, I think the UAS should include as many codecs that the UA is
> willing(section 14.2 of RFC3261) to support. I think we should let the
> UA has the right to decide which codecs can be use or not for this
> current call. At the same time, the UAS should be with responsibility
> for failure of session if it cut down the number of codecs. UAS's
> willing of codecs can be implemented as local policy or some other forms
> of configuration.

Yes, this just requires minor tweak to wording.
Its consistent with the recommendations on sendonly/...

> For media types, it is almost the same as codecs, about UA's willing.
> But I think we should emphasize on avoiding of introducing new media
> types without user's permission, such as just introducing new media
> types  by equipment or software. Beacause I have met such charging
> arguement from users in some operating telecom-network.(If you want the
> detail of the charging arguement, I'd like to share it with you).
> So, if there is no indication of permission of introducing new media
> types from the end user, UAS should just include current using media
> types. And if the other side(user of UAC) want to add media types, it
> can using another new Offer.

I get your point and agree. Its the same concept - include everything
the UA would be willing to use, not just that which it thinks the peer
wants to use.

                Thanks,
                Paul

> Thanks,
>
> Gao
>
> Section 14.2 of RFC3261:
> A UAS providing an offer in a 2xx (because the INVITE did not contain
>    an offer) SHOULD construct the offer as if the UAS were making a
>    brand new call, subject to the constraints of sending an offer that
>    updates an existing session, as described in [13] in the case of SDP.
>    Specifically, this means that it SHOULD include as many media formats
>    and media types that the UA *is willing to support*.  The UAS MUST
>    ensure that the session description overlaps with its previous
>    session description in media formats, transports, or other parameters
>    that require support from the peer.  This is to avoid the need for
>    the peer to reject the session description.  
>
> ===================================
> Zip    : 210012
> Tel    : 87211
> Tel2   :(+86)-025-52877211
> e_mail : gao.yang2 <at> zte.com.cn
> ===================================
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>



-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
Sipping mailing list  https://www.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
Internet-Drafts | 2 Mar 23:00 2010
Picon

I-D Action:draft-ietf-sipping-policy-package-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title           : A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies.
	Author(s)       : V. Hilt, G. Camarillo
	Filename        : draft-ietf-sipping-policy-package-07.txt
	Pages           : 18
	Date            : 2010-03-02

This specification defines a Session Initiation Protocol (SIP) event
package for session-specific policies.  This event package enables
user agents to subscribe to session policies for a SIP session and to
receive notifications if these policies change.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy-package-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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://www.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 | 3 Mar 00:20 2010

Re: Hi Paul //About draft-ietf-sipping-sip-offeranswer-11

offeranswer was the informational document that examined poor usage of existing normative specification text in RFC 3264. It is not intended to carry nomative information in its own right.
 
If you feel normative language is needed, then you need a document that updates RFC 3264, either as a separate document or one that replaces it. We have talked about that in the past as part of the SIP work, shortly before the SIP group got closed.
 
regards
 
Keith

From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On Behalf Of gao.yang2 <at> zte.com.cn
Sent: Tuesday, March 02, 2010 7:02 AM
To: Paul Kyzivat
Cc: sipping
Subject: Re: [Sipping] Hi Paul //About draft-ietf-sipping-sip-offeranswer-11


Hi Paul,

I just feel adding some BCP level description (something like the description below) would let people do system design and implement clearly.

"When recv Re-INVITE without Offer, UAS SHOULD avoid of introducing new media types without user's permission or local policy configuration, that is its current using media types."

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2 <at> zte.com.cn
===================================
----- 转发人 GaoYang140197/user/zte_ltd 时间 2010-03-02 14:56 -----
GaoYang140197/user/zte_ltd

2010-03-01 13:44

收件人
Paul Kyzivat <pkyzivat <at> cisco.com>
抄送
sipping <sipping <at> ietf.org>
主题
Re: Hi Paul  //About draft-ietf-sipping-sip-offeranswer-11链接





As you have a new version, I think including sipping would be better :)

Thanks for your agreement at this point.

But as RFC3261's words of "willings" is not as clear as guidance for system design and implement, I think some BCP level description vcould be better.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2 <at> zte.com.cn
===================================


Paul Kyzivat <pkyzivat <at> cisco.com>

2010-02-26 22:17

收件人
gao.yang2 <at> zte.com.cn
抄送
sipping <sipping <at> ietf.org>
主题
Re: Hi Paul  //About draft-ietf-sipping-sip-offeranswer-11







gao.yang2 <at> zte.com.cn wrote:
>
> I just find a potential problem of
> draft-ietf-sipping-sip-offeranswer-11. I am not sure will you want have
> a new version, so I send this discussion offline.

I am working on another version. I am including sipping in my response
so others have the opportunity to comment. (I trust that is ok.)

> Section 5.2.5. of draft-ietf-sipping-sip-offeranswer-11:
> When the new offer is sent in response to an offerless (re)INVITE,
>    *all codecs supported by the UA are to be included*, not just the ones
>    that were negotiated by previous offer/answer exchanges.  *The same is*
> *   true for media types* - so if UA A initially offered audio and video
>    to UA B, and they end up with only audio, and UA B sends an offerless
>    (re)INVITE to UA A, A's resulting offer should re- attempt video, by
>    reusing the zeroed m-line used previously.
>
>
> While Re-INVITE without Offer:
> For codecs, I think the UAS should include as many codecs that the UA is
> willing(section 14.2 of RFC3261) to support. I think we should let the
> UA has the right to decide which codecs can be use or not for this
> current call. At the same time, the UAS should be with responsibility
> for failure of session if it cut down the number of codecs. UAS's
> willing of codecs can be implemented as local policy or some other forms
> of configuration.

Yes, this just requires minor tweak to wording.
Its consistent with the recommendations on sendonly/...

> For media types, it is almost the same as codecs, about UA's willing.
> But I think we should emphasize on avoiding of introducing new media
> types without user's permission, such as just introducing new media
> types  by equipment or software. Beacause I have met such charging
> arguement from users in some operating telecom-network.(If you want the
> detail of the charging arguement, I'd like to share it with you).
> So, if there is no indication of permission of introducing new media
> types from the end user, UAS should just include current using media
> types. And if the other side(user of UAC) want to add media types, it
> can using another new Offer.

I get your point and agree. Its the same concept - include everything
the UA would be willing to use, not just that which it thinks the peer
wants to use.

                Thanks,
                Paul

> Thanks,
>
> Gao
>
> Section 14.2 of RFC3261:
> A UAS providing an offer in a 2xx (because the INVITE did not contain
>    an offer) SHOULD construct the offer as if the UAS were making a
>    brand new call, subject to the constraints of sending an offer that
>    updates an existing session, as described in [13] in the case of SDP.
>    Specifically, this means that it SHOULD include as many media formats
>    and media types that the UA *is willing to support*.  The UAS MUST
>    ensure that the session description overlaps with its previous
>    session description in media formats, transports, or other parameters
>    that require support from the peer.  This is to avoid the need for
>    the peer to reject the session description.  
>
> ===================================
> Zip    : 210012
> Tel    : 87211
> Tel2   :(+86)-025-52877211
> e_mail : gao.yang2 <at> zte.com.cn
> ===================================
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>



-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
Sipping mailing list  https://www.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
Paul Kyzivat | 3 Mar 00:40 2010
Picon

Re: Hi Paul //About draft-ietf-sipping-sip-offeranswer-11

I agree that this sort of thing is best practice suggestion and should
not contain normative language.

	Thanks,
	Paul

DRAGE, Keith (Keith) wrote:
> offeranswer was the informational document that examined poor usage of 
> existing normative specification text in RFC 3264. It is not intended to 
> carry nomative information in its own right.
>  
> If you feel normative language is needed, then you need a document that 
> updates RFC 3264, either as a separate document or one that replaces it. 
> We have talked about that in the past as part of the SIP work, shortly 
> before the SIP group got closed.
>  
> regards
>  
> Keith
> 
>     ------------------------------------------------------------------------
>     *From:* sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org]
>     *On Behalf Of *gao.yang2 <at> zte.com.cn
>     *Sent:* Tuesday, March 02, 2010 7:02 AM
>     *To:* Paul Kyzivat
>     *Cc:* sipping
>     *Subject:* Re: [Sipping] Hi Paul //About
>     draft-ietf-sipping-sip-offeranswer-11
> 
> 
>     Hi Paul,
> 
>     I just feel adding some BCP level description (something like the
>     description below) would let people do system design and implement
>     clearly.
> 
>     "When recv Re-INVITE without Offer, UAS SHOULD avoid of introducing
>     new media types without user's permission or local policy
>     configuration, that is its current using media types."
> 
>     Thanks,
> 
>     Gao
> 
>     ===================================
>     Zip    : 210012
>     Tel    : 87211
>     Tel2   :(+86)-025-52877211
>     e_mail : gao.yang2 <at> zte.com.cn
>     ===================================
>     ----- 转发人 GaoYang140197/user/zte_ltd 时间 2010-03-02 14:56 -----
>     *GaoYang140197/user/zte_ltd*
> 
>     2010-03-01 13:44
> 
>     	
>     收件人
>     	Paul Kyzivat <pkyzivat <at> cisco.com>
>     抄送
>     	sipping <sipping <at> ietf.org>
>     主题
>     	Re: Hi Paul  //About draft-ietf-sipping-sip-offeranswer-11链接
>     <Notes://NJMAIL01/48257169002DF8EE/DABA975B9FB113EB852564B5001283EA/A95B47510FB03B93482576D6004E7AE9>
> 
> 
>     	
> 
> 
> 
> 
> 
>     As you have a new version, I think including sipping would be better :)
> 
>     Thanks for your agreement at this point.
> 
>     But as RFC3261's words of "willings" is not as clear as guidance for
>     system design and implement, I think some BCP level description
>     vcould be better.
> 
>     Thanks,
> 
>     Gao
> 
>     ===================================
>     Zip    : 210012
>     Tel    : 87211
>     Tel2   :(+86)-025-52877211
>     e_mail : gao.yang2 <at> zte.com.cn
>     ===================================
> 
> 
>     *Paul Kyzivat <pkyzivat <at> cisco.com>*
> 
>     2010-02-26 22:17
> 
>     	
>     收件人
>     	gao.yang2 <at> zte.com.cn
>     抄送
>     	sipping <sipping <at> ietf.org>
>     主题
>     	Re: Hi Paul  //About draft-ietf-sipping-sip-offeranswer-11
> 
> 
>     	
> 
> 
> 
> 
> 
> 
> 
>     gao.yang2 <at> zte.com.cn wrote:
>      >
>      > I just find a potential problem of
>      > draft-ietf-sipping-sip-offeranswer-11. I am not sure will you
>     want have
>      > a new version, so I send this discussion offline.
> 
>     I am working on another version. I am including sipping in my response
>     so others have the opportunity to comment. (I trust that is ok.)
> 
>      > Section 5.2.5. of draft-ietf-sipping-sip-offeranswer-11:
>      > When the new offer is sent in response to an offerless (re)INVITE,
>      >    *all codecs supported by the UA are to be included*, not just
>     the ones
>      >    that were negotiated by previous offer/answer exchanges.  *The
>     same is*
>      > *   true for media types* - so if UA A initially offered audio
>     and video
>      >    to UA B, and they end up with only audio, and UA B sends an
>     offerless
>      >    (re)INVITE to UA A, A's resulting offer should re- attempt
>     video, by
>      >    reusing the zeroed m-line used previously.
>      >
>      >
>      > While Re-INVITE without Offer:
>      > For codecs, I think the UAS should include as many codecs that
>     the UA is
>      > willing(section 14.2 of RFC3261) to support. I think we should
>     let the
>      > UA has the right to decide which codecs can be use or not for this
>      > current call. At the same time, the UAS should be with
>     responsibility
>      > for failure of session if it cut down the number of codecs. UAS's
>      > willing of codecs can be implemented as local policy or some
>     other forms
>      > of configuration.
> 
>     Yes, this just requires minor tweak to wording.
>     Its consistent with the recommendations on sendonly/...
> 
>      > For media types, it is almost the same as codecs, about UA's
>     willing.
>      > But I think we should emphasize on avoiding of introducing new media
>      > types without user's permission, such as just introducing new media
>      > types  by equipment or software. Beacause I have met such charging
>      > arguement from users in some operating telecom-network.(If you
>     want the
>      > detail of the charging arguement, I'd like to share it with you).
>      > So, if there is no indication of permission of introducing new media
>      > types from the end user, UAS should just include current using media
>      > types. And if the other side(user of UAC) want to add media
>     types, it
>      > can using another new Offer.
> 
>     I get your point and agree. Its the same concept - include everything
>     the UA would be willing to use, not just that which it thinks the peer
>     wants to use.
> 
>                     Thanks,
>                     Paul
> 
>      > Thanks,
>      >
>      > Gao
>      >
>      > Section 14.2 of RFC3261:
>      > A UAS providing an offer in a 2xx (because the INVITE did not contain
>      >    an offer) SHOULD construct the offer as if the UAS were making a
>      >    brand new call, subject to the constraints of sending an offer
>     that
>      >    updates an existing session, as described in [13] in the case
>     of SDP.
>      >    Specifically, this means that it SHOULD include as many media
>     formats
>      >    and media types that the UA *is willing to support*.  The UAS MUST
>      >    ensure that the session description overlaps with its previous
>      >    session description in media formats, transports, or other
>     parameters
>      >    that require support from the peer.  This is to avoid the need for
>      >    the peer to reject the session description.  
>      >
>      > ===================================
>      > Zip    : 210012
>      > Tel    : 87211
>      > Tel2   :(+86)-025-52877211
>      > e_mail : gao.yang2 <at> zte.com.cn
>      > ===================================
>      >
>      > --------------------------------------------------------
>      > ZTE Information Security Notice: The information contained in
>     this mail is solely property of the sender's organization. This mail
>     communication is confidential. Recipients named above are obligated
>     to maintain secrecy and are not permitted to disclose the contents
>     of this communication to others.
>      > This email and any files transmitted with it are confidential and
>     intended solely for the use of the individual or entity to whom they
>     are addressed. If you have received this email in error please
>     notify the originator of the message. Any views expressed in this
>     message are those of the individual sender.
>      > This message has been scanned for viruses and Spam by ZTE
>     Anti-Spam system.
>      >
> 
> 
> 
>     --------------------------------------------------------
>     ZTE Information Security Notice: The information contained in this mail is solely property of the
sender's organization. This mail communication is confidential. Recipients named above are obligated
to maintain secrecy and are not permitted to disclose the contents of this communication to others.
>     This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify the
originator of the message. Any views expressed in this message are those of the individual sender.
>     This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
Sipping mailing list  https://www.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
gao.yang2 | 3 Mar 01:55 2010
Picon

答复: Re: Hi Paul //About draft-ietf-sipping-sip-offeranswer-11


I also agree with Keith that normative correction should be in a (new) standard track text aimed for RFC3264. So, the key is whether my suggestion is BCP level or not, Paul?

But I still think my suggestion is BCP level, not normative. The reason is that it is not intend to exclude the behavior not obeying the suggestion. UAS introducing new media types without user's permission can still make the call OK.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2 <at> zte.com.cn
===================================


Paul Kyzivat <pkyzivat <at> cisco.com>

2010-03-03 07:40

收件人
"DRAGE, Keith (Keith)" <keith.drage <at> alcatel-lucent.com>
抄送
"gao.yang2 <at> zte.com.cn" <gao.yang2 <at> zte.com.cn>, sipping <sipping <at> ietf.org>
主题
Re: [Sipping] Hi Paul //About draft-ietf-sipping-sip-offeranswer-11





I agree that this sort of thing is best practice suggestion and should
not contain normative language.

                Thanks,
                Paul

DRAGE, Keith (Keith) wrote:
> offeranswer was the informational document that examined poor usage of
> existing normative specification text in RFC 3264. It is not intended to
> carry nomative information in its own right.
>  
> If you feel normative language is needed, then you need a document that
> updates RFC 3264, either as a separate document or one that replaces it.
> We have talked about that in the past as part of the SIP work, shortly
> before the SIP group got closed.
>  
> regards
>  
> Keith
>
>     ------------------------------------------------------------------------
>     *From:* sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org]
>     *On Behalf Of *gao.yang2 <at> zte.com.cn
>     *Sent:* Tuesday, March 02, 2010 7:02 AM
>     *To:* Paul Kyzivat
>     *Cc:* sipping
>     *Subject:* Re: [Sipping] Hi Paul //About
>     draft-ietf-sipping-sip-offeranswer-11
>
>
>     Hi Paul,
>
>     I just feel adding some BCP level description (something like the
>     description below) would let people do system design and implement
>     clearly.
>
>     "When recv Re-INVITE without Offer, UAS SHOULD avoid of introducing
>     new media types without user's permission or local policy
>     configuration, that is its current using media types."
>
>     Thanks,
>
>     Gao
>
>     ===================================
>     Zip    : 210012
>     Tel    : 87211
>     Tel2   :(+86)-025-52877211
>     e_mail : gao.yang2 <at> zte.com.cn
>     ===================================
>     ----- 转发人 GaoYang140197/user/zte_ltd 时间 2010-03-02 14:56 -----
>     *GaoYang140197/user/zte_ltd*
>
>     2010-03-01 13:44
>
>                      
>     收件人
>                      Paul Kyzivat <pkyzivat <at> cisco.com>
>     抄送
>                      sipping <sipping <at> ietf.org>
>     主题
>                      Re: Hi Paul  //About draft-ietf-sipping-sip-offeranswer-11链接
>     <Notes://NJMAIL01/48257169002DF8EE/DABA975B9FB113EB852564B5001283EA/A95B47510FB03B93482576D6004E7AE9>
>
>
>                      
>
>
>
>
>
>     As you have a new version, I think including sipping would be better :)
>
>     Thanks for your agreement at this point.
>
>     But as RFC3261's words of "willings" is not as clear as guidance for
>     system design and implement, I think some BCP level description
>     vcould be better.
>
>     Thanks,
>
>     Gao
>
>     ===================================
>     Zip    : 210012
>     Tel    : 87211
>     Tel2   :(+86)-025-52877211
>     e_mail : gao.yang2 <at> zte.com.cn
>     ===================================
>
>
>     *Paul Kyzivat <pkyzivat <at> cisco.com>*
>
>     2010-02-26 22:17
>
>                      
>     收件人
>                      gao.yang2 <at> zte.com.cn
>     抄送
>                      sipping <sipping <at> ietf.org>
>     主题
>                      Re: Hi Paul  //About draft-ietf-sipping-sip-offeranswer-11
>
>
>                      
>
>
>
>
>
>
>
>     gao.yang2 <at> zte.com.cn wrote:
>      >
>      > I just find a potential problem of
>      > draft-ietf-sipping-sip-offeranswer-11. I am not sure will you
>     want have
>      > a new version, so I send this discussion offline.
>
>     I am working on another version. I am including sipping in my response
>     so others have the opportunity to comment. (I trust that is ok.)
>
>      > Section 5.2.5. of draft-ietf-sipping-sip-offeranswer-11:
>      > When the new offer is sent in response to an offerless (re)INVITE,
>      >    *all codecs supported by the UA are to be included*, not just
>     the ones
>      >    that were negotiated by previous offer/answer exchanges.  *The
>     same is*
>      > *   true for media types* - so if UA A initially offered audio
>     and video
>      >    to UA B, and they end up with only audio, and UA B sends an
>     offerless
>      >    (re)INVITE to UA A, A's resulting offer should re- attempt
>     video, by
>      >    reusing the zeroed m-line used previously.
>      >
>      >
>      > While Re-INVITE without Offer:
>      > For codecs, I think the UAS should include as many codecs that
>     the UA is
>      > willing(section 14.2 of RFC3261) to support. I think we should
>     let the
>      > UA has the right to decide which codecs can be use or not for this
>      > current call. At the same time, the UAS should be with
>     responsibility
>      > for failure of session if it cut down the number of codecs. UAS's
>      > willing of codecs can be implemented as local policy or some
>     other forms
>      > of configuration.
>
>     Yes, this just requires minor tweak to wording.
>     Its consistent with the recommendations on sendonly/...
>
>      > For media types, it is almost the same as codecs, about UA's
>     willing.
>      > But I think we should emphasize on avoiding of introducing new media
>      > types without user's permission, such as just introducing new media
>      > types  by equipment or software. Beacause I have met such charging
>      > arguement from users in some operating telecom-network.(If you
>     want the
>      > detail of the charging arguement, I'd like to share it with you).
>      > So, if there is no indication of permission of introducing new media
>      > types from the end user, UAS should just include current using media
>      > types. And if the other side(user of UAC) want to add media
>     types, it
>      > can using another new Offer.
>
>     I get your point and agree. Its the same concept - include everything
>     the UA would be willing to use, not just that which it thinks the peer
>     wants to use.
>
>                     Thanks,
>                     Paul
>
>      > Thanks,
>      >
>      > Gao
>      >
>      > Section 14.2 of RFC3261:
>      > A UAS providing an offer in a 2xx (because the INVITE did not contain
>      >    an offer) SHOULD construct the offer as if the UAS were making a
>      >    brand new call, subject to the constraints of sending an offer
>     that
>      >    updates an existing session, as described in [13] in the case
>     of SDP.
>      >    Specifically, this means that it SHOULD include as many media
>     formats
>      >    and media types that the UA *is willing to support*.  The UAS MUST
>      >    ensure that the session description overlaps with its previous
>      >    session description in media formats, transports, or other
>     parameters
>      >    that require support from the peer.  This is to avoid the need for
>      >    the peer to reject the session description.  
>      >
>      > ===================================
>      > Zip    : 210012
>      > Tel    : 87211
>      > Tel2   :(+86)-025-52877211
>      > e_mail : gao.yang2 <at> zte.com.cn
>      > ===================================
>      >
>      > --------------------------------------------------------
>      > ZTE Information Security Notice: The information contained in
>     this mail is solely property of the sender's organization. This mail
>     communication is confidential. Recipients named above are obligated
>     to maintain secrecy and are not permitted to disclose the contents
>     of this communication to others.
>      > This email and any files transmitted with it are confidential and
>     intended solely for the use of the individual or entity to whom they
>     are addressed. If you have received this email in error please
>     notify the originator of the message. Any views expressed in this
>     message are those of the individual sender.
>      > This message has been scanned for viruses and Spam by ZTE
>     Anti-Spam system.
>      >
>
>
>
>     --------------------------------------------------------
>     ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
>     This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
>     This message has been scanned for viruses and Spam by ZTE Anti-Spam system.



-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
Sipping mailing list  https://www.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
Dale Worley | 3 Mar 21:42 2010

Re: I-D Action:draft-ietf-sipping-policy-package-07.txt

On Tue, 2010-03-02 at 14:00 -0800, Internet-Drafts <at> ietf.org wrote:
> 	Title           : A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies.
> 	Author(s)       : V. Hilt, G. Camarillo
> 	Filename        : draft-ietf-sipping-policy-package-07.txt
> 	Pages           : 18
> 	Date            : 2010-03-02

The phrase "Session-Specific Session Policies" sounds redundant.  Would
it be reasonable to change it to "... Event Package for Session
Policies", or "... Event Package for Policies for a Session"?

Dale

_______________________________________________
Sipping mailing list  https://www.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

Dale Worley | 3 Mar 23:43 2010

Re: Question on draft-ietf-sipping-v6-transition-07

On Fri, 2010-02-05 at 09:03 -0600, Kevin P. Fleming wrote:
> That would in fact be wrong, domain names cannot begin with '.'. In
> addition, I'd recommend against allowing an 'invalid' name that does not
> contain '.', because many systems (including my laptop) are configured
> with default DNS search domains that are searched when names that
> contain only one component are resolved. 'invalid' in my case would
> search in at least two domains for 'invalid.xxx.yyy', which is not
> helpful in the context of this draft.
> 
> Explicitly specifying 'this.is.invalid' or something similar seems to be
> prudent in this case.

That's an interesting point.  As you note, "invalid" is a perfectly
valid DNS name that is reserved.  But it might be subject to bad
resolver behavior.  Indeed, IIRC some popular resolvers will always
search multiple configured domains unless the name given to them is
ended with an extra "." (which seems to be allowed for in the syntax).
But any SIP implementation should use its local resolver in such a way
that such additional searches are never done.

But how many SIP implementations do that correctly?

Dale

_______________________________________________
Sipping mailing list  https://www.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

Volker Hilt | 5 Mar 22:56 2010

draft-ietf-sipping-media-policy-dataset

I have posted a new version of the
draft-ietf-sipping-media-policy-dataset. The new version has all
dependencies on the dataset framework removed and should now be stand
alone. The draft will still need some more cleanup. Any comments and
feedback are very welcome.

Thanks,

Volker

------------
A new version of I-D, draft-ietf-sipping-media-policy-dataset-09.txt has
been successfuly submitted by Volker Hilt and posted to the IETF repository.

Filename:	 draft-ietf-sipping-media-policy-dataset
Revision:	 09
Title:		 A User Agent Profile Data Set for Media Policy
Creation_date:	 2010-03-05
WG ID:		 sipping
Number_of_pages: 39

Abstract:
This specification defines a document format for the media properties
of Session Initiation Protocol (SIP) sessions.  Examples for media
properties are the codecs or media types used in a session.  This
document format is based on XML and can be used to describe the
properties of a specific SIP session or to define policies that are
then applied to SIP sessions.

The IETF Secretariat.

_______________________________________________
Sipping mailing list  https://www.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