Re: I-D ACTION:draft-ietf-sipping-uri-list-message-06.txt

Hi Jari:

Thanks for the comment. I think it is a good idea to add the <import> 
statement to the schema.

As a side-by comment: I think we shouldn't add a local file name, such 
as "xcap-list.xsd" the schemaLocation attribute. I first tried to 
include instead a permanent URI, such as 
http://www.iana.org/assignments/xml-registry/schema/resource-lists.xsd 
but there is an error with the file in IANA, because the first "<?xml" 
tag begins in the 3rd column of the first line, rather in than in the 
first column. I suspect all these files have been directly extracted 
from the RFC that leaves 2 empty spaces at the beginning, something that 
most validators, including http://validate.openlaboratory.net/ don't like.

So I am afraid we need to stick to the local file name.

BR,

       Miguel

Jari Urpalainen wrote:
>>  
>>
> Still another schema related comment. While there's an increasing amount 
> of i-d's that extend a base schema (mime-type defined) there's not a 
> BCP, AFAIK, how extension schemas should reference the base schemas. 
> With w3c schemas, a simple way to tell this to the validating process, 
> is to use <xs:import> or <xs:include> statements within the extension 
> schema. So I'd propose to add <xs:import> into this schema to explicitly 

Re: I-D ACTION:draft-ietf-sipping-uri-list-message-06.txt

ext sipping-bounces <at> ietf.org wrote:

>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		: Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)
>	Author(s)	: M. Garcia-Martin, G. Camarillo
>	Filename	: draft-ietf-sipping-uri-list-message-06.txt
>	Pages		: 20
>	Date		: 2006-1-31
>	
>This document specifies how to request a SIP URI-list service to send
>   a copy of a MESSAGE to a set of destinations.  The client sends a SIP
>   MESSAGE request with a URI-list to the MESSAGE URI-list service,
>   which sends a similar MESSAGE request to each of the URIs included in
>   the list.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list-message-06.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>i-d-announce-request <at> ietf.org 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.
>  
>
Still another schema related comment. While there's an increasing amount 
of i-d's that extend a base schema (mime-type defined) there's not a 
BCP, AFAIK, how extension schemas should reference the base schemas. 
With w3c schemas, a simple way to tell this to the validating process, 

Fwd: Last Call: 'Diameter Session Initiation Protocol (SIP) Application' to Proposed Standard

FYI

Begin forwarded message:

> From: The IESG <iesg-secretary <at> ietf.org>
> Date: January 25, 2006 10:31:45 AM CST
> To: IETF-Announce <ietf-announce <at> ietf.org>
> Cc: aaa-wg <at> merit.edu
> Subject: Last Call: 'Diameter Session Initiation Protocol (SIP)  
> Application' to Proposed Standard
> Reply-To: iesg <at> ietf.org
>
> The IESG has received a request from the Authentication,  
> Authorization and
> Accounting WG to consider the following document:
>
> - 'Diameter Session Initiation Protocol (SIP) Application '
>    <draft-ietf-aaa-diameter-sip-app-10.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2006-02-08.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip- 
> app-10.txt
>
>
> _______________________________________________
> IETF-Announce mailing list

Re: I-D ACTION:draft-ietf-sipping-uri-list-message-06.txt

So, I have added Jari's suggestion to my working copy of this draft. I 
am planning to submit it on Monday. If anyone has any last-minute 
comment, we can bring it on board.

/Miguel

Miguel Garcia wrote:
> Hi Jari:
> 
> Thanks for the comment. I think it is a good idea to add the <import> 
> statement to the schema.
> 
> As a side-by comment: I think we shouldn't add a local file name, such 
> as "xcap-list.xsd" the schemaLocation attribute. I first tried to 
> include instead a permanent URI, such as 
> http://www.iana.org/assignments/xml-registry/schema/resource-lists.xsd 
> but there is an error with the file in IANA, because the first "<?xml" 
> tag begins in the 3rd column of the first line, rather in than in the 
> first column. I suspect all these files have been directly extracted 
> from the RFC that leaves 2 empty spaces at the beginning, something that 
> most validators, including http://validate.openlaboratory.net/ don't like.
> 
> So I am afraid we need to stick to the local file name.
> 
> BR,
> 
> 
>       Miguel
> 
> 

consent framework

_______________________________________________
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

FW: I-D ACTION:draft-rocky-sipping-override-barring-00.txt

Hi, All,
    An initial draft is available now. It has collected some appoaches
for overriding barring services.
    Please kindly give your comments. And if you find some more
appoaches, please let me know.

Best regards,
Rocky Wang

-----Original Message-----
From: i-d-announce-bounces <at> ietf.org
[mailto:i-d-announce-bounces <at> ietf.org] On Behalf Of
Internet-Drafts <at> ietf.org
Sent: 2006年1月27日 4:50
To: i-d-announce <at> ietf.org
Subject: I-D ACTION:draft-rocky-sipping-override-barring-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: A method to override the barring services
	Author(s)	: R. Wang
	Filename	: draft-rocky-sipping-override-barring-00.txt
	Pages		: 25
	Date		: 2006-1-26
	
   The document collects some approaches used to implement the
   functionalities of Override Barring Services in Session Initial
   Protocol (SIP), and gives detailed description of service flows for
   each type of the functionalities. Some methods such as SAML, CPC,
   which is used to implement service, are also dealt with in the
   document.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-rocky-sipping-override-barring
-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org 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-rocky-sipping-override-barring-00.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:
	mailserv <at> ietf.org.
In the body type:
	"FILE
/internet-drafts/draft-rocky-sipping-override-barring-00.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.

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
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

RE: New I-D - SIP Subscription Mobility using SUBSCRIBEwithReplaces Header

Not very sure about this....but can this draft be made more generic in order
to address the issue of transparent fail over for SIP servers. It can apply
to all dialog creating SIP messages (INVITE / SUBSCRIBE / REFER). 

Can it act as a BCP document for all SIP entities wishing to implement a
transparent failover mechanism?

Is there any such mechanism documented? How a SIP server can transfer all
SIP dialogs and state to another SIP Server when it is being shutdown...

-----Original Message-----
From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On Behalf
Of Horvath Bob-BHORVAT1
Sent: Wednesday, February 01, 2006 12:39 AM
To: Paul Kyzivat
Cc: sipping <at> ietf.org
Subject: Re: [Sipping] New I-D - SIP Subscription Mobility using
SUBSCRIBEwithReplaces Header

Paul Kyzivat wrote:
> [Replying to the whole thread, not just this message.]
>
>
...
>
> One advantage of this approach seems false to me. There seems to be an 
> assumption that upon receipt of a SUBSCRIBE/Replaces, the notifier 
> will just drop the replaced subscription without sending a NOTIFY. 
> That is analogous to the recipient of an INVITE/Replaces dropping the 
> replaced call without sending a BYE. That isn't how it works. There in 
> general is no guarantee that the peer in the old dialog is aware that 
> this is happening.
>
> If it is desired to have the old subscription dropped without any 
> notification, then I think there needs to be something new added to 
> the signaling that explicitly requests that behavior. And, there may 
> be some security considerations around that. (I haven't thought this 
> through.)
>

I agree, although I can see why as written it is not obvious because we 
wrote it from the perspective of the new subscription without much 
discussion on what happens to the existing subscription.  When we said 
the old subscription is removed, we deferred to 3265 to define what that 
means.  3265 indicates that when removing a subscription, the notifier 
should send a NOTIFY to indicate that it is terminating the existing 
subscription. 

_______________________________________________
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

RE: [Sipping-tispan] FW: I-DACTION:draft-rocky-sipping-override-barring-00.txt

Hi, all,
   More background information about this draft is maybe useful for you
when you begin read it.

   In the last IETF meeting in Vancouver, I have submitted a draft to
implement the functionality to override barring service in use of an
extion header, P-CPC (See in
draft-rocky-sipping-calling-party-category-01) which is also mentioned
in this draft. Because more issues must be re-considered. A key one is
the security consideration because the called network server will not
always know whether the information is provided by a real calling
network server, or some other malformed attacker. This is a problem if
the network diagram is not decided. As experts sugestion, I tried to
search for an appoach in use of SAML.

   SAML can be used to convey a set of information, include the
authentication information and calling party features. There is team
researching on the deploy SAML in SIP (Ses in
draft-tschofenig-sip-saml-04.txt).

   I have collected some types of the functionalities to override
barring services. Maybe there are some more. Would you please tell me if
you know. And for listed types, there maybe some more typical appoaches.
I thank you too to receives more appoaches from you. Any comments are
welcome.

Best Regards,
Rocky Wang

> -----Original Message-----
> From: sipping-tispan-bounces <at> ietf.org 
> [mailto:sipping-tispan-bounces <at> ietf.org] On Behalf Of Rocky Wang
> Sent: 2006年2月5日 17:11
> To: sipping <at> ietf.org; sipping-tispan <at> ietf.org
> Subject: [Sipping-tispan] FW: 
> I-DACTION:draft-rocky-sipping-override-barring-00.txt
> 
> 
> Hi, All,
>     An initial draft is available now. It has collected some 
> appoaches for overriding barring services.
>     Please kindly give your comments. And if you find some 
> more appoaches, please let me know.
> 
> Best regards,
> Rocky Wang
> 
> 
> -----Original Message-----
> From: i-d-announce-bounces <at> ietf.org 
> [mailto:i-d-announce-bounces <at> ietf.org] On Behalf Of 
> Internet-Drafts <at> ietf.org
> Sent: 2006年1月27日 4:50
> To: i-d-announce <at> ietf.org
> Subject: I-D ACTION:draft-rocky-sipping-override-barring-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: A method to override the barring services
> 	Author(s)	: R. Wang
> 	Filename	: draft-rocky-sipping-override-barring-00.txt
> 	Pages		: 25
> 	Date		: 2006-1-26
> 	
>    The document collects some approaches used to implement the
>    functionalities of Override Barring Services in Session Initial
>    Protocol (SIP), and gives detailed description of service flows for
>    each type of the functionalities. Some methods such as SAML, CPC,
>    which is used to implement service, are also dealt with in the
>    document.
> 
> A URL for this Internet-Draft is:
>  
http://www.ietf.org/internet-drafts/draft-rocky-sipping-override-barring
-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org 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-rocky-sipping-override-barring-00.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:
	mailserv <at> ietf.org.
In the body type:
	"FILE
/internet-drafts/draft-rocky-sipping-override-barring-00.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 sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Re: OMA thoughts on draft-ietf-sipping-uri-list-conferencing-04.txt and "cc" and "bcc" lists.

Hi,

if somebody thinks this is controversial, we could have OMA author a new 
draft. However, if nobody opposes to what Dean suggests below, my 
proposal would be to include it in the existing draft.

Cheers,

Gonzalo

Dean Willis wrote:
> 
> OM is looking at uri-list conferencing for their push-to-talk work. .
> 
> One of their needs is to inform POC recipients of the "cc" list -- that 
> is, the set of other URIs invited to the conference. They also have a 
> need for "bcc" participants who get invited but not advertised.
> 
> This is allowed for in the message-list work 
> (draft-ietf-sipping-uri-list-message-06.txt) by having the message 
> exploder include a copy of the recipient list on outbound messages, and 
> allows for tagging each target as a "to", "cc" or "bcc" using the usual 
> email semantics.
> 
> 
> Should we:
> 
> 1) Address this in our uri-list draft before publishing it (it's past 
> WGLC).
> 
> 2) Request OMA author a draft that extends our draft.
> 
> 
> I believe we could basically paste the recipient-notification text from 
> uri-list-message into uri-list-conferencing. But this is a fairly late 
> phase to be changing the requirements.
> 
> -- 
> Dean
> 

--

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo <at> ericsson.com
Finland                   http://www.hut.fi/~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

New OMA suggested requirements for draft-ietf-sipping-uri-list-conferencing-04.txt

OM is looking at uri-list conferencing for their push-to-talk work. .

One of their needs is to inform POC recipients of the "cc" list --  
that is, the set of other URIs invited to the conference. They also  
have a need for "bcc" participants who get invited but not advertised.

This is allowed for in the message-list work (draft-ietf-sipping-uri- 
list-message-06.txt) by having the message exploder include a copy of  
the recipient list on outbound messages, and allows for tagging each  
target as a "to", "cc" or "bcc" using the usual email semantics.

Should we:

1) Address this in our uri-list draft before publishing it (it's past  
WGLC).

2) Request OMA author a draft that extends our draft.

I believe we could basically paste the recipient-notification text  
from uri-list-message into uri-list-conferencing. But this is a  
fairly late phase to be changing the requirements.

To meet the full set of conferencing requirements in current OMA  
discussions, we would also need to add the role 'anonymous' and add  
some discussion of how the roles interact with the conference-package  
notifications.

What do you think?

--
Dean

_______________________________________________
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