headers
The IESG | 1 Aug 2003 21:04
Picon
Favicon

Protocol Action: 'Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration' to Proposed Standard

The IESG has approved the Internet-Draft 'Session Initiation Protocol 
Extension Header Field for Service Route Discovery During Registration' 
<draft-ietf-sip-scvrtdisco-04.txt> as a Proposed Standard. This document is 
the product of the Session Initiation Protocol Working Group. The IESG 
contact persons are Allison Mankin and Jon Peterson.

Technical Summary

            This document defines a SIP extension header field used in
            conjunction with responses to REGISTER requests to provide a
            mechanism by which a registrar may inform a registering User
            Agent (UA), that is, an end-user, of a service route that the UA
            may use to request outbound services from the registrar's domain.

            SIP has a Route Header which is used to loose source route
            messages, and this Service Route extension allows providers to
            offer plans in which a user can ensure that they visit a provider's
            proxy at which they registered. IETF protocols should neither favor
            nor preclude* such capabilities. Security for the user and the
            provider are provided by the use of the SIP sips: address of record
            mandating that the hops be carried over TLS, and use of S/MIME for
            the bodies in the messages.

                                                                                
Working Group Summary

            There was active review. This document was split out from
            the other direction, called the PATH header and worked on until
            it had adequate clarity and security. Its current version has
            good consensus.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 Aug 2003 21:29
Picon
Favicon

I-D ACTION:draft-ietf-sip-mib-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 Protocol Working Group of the IETF.

	Title		: Management Information Base for Session Initiation 
                          Protocol (SIP)
	Author(s)	: K. Lingle, J. Maeng, J. Mule, D. Walker
	Filename	: draft-ietf-sip-mib-07.txt
	Pages		: 116
	Date		: 2003-8-1
	
This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in the Internet community.  
In particular, it describes a set of managed objects that are used 
to manage Session Initiation Protocol (SIP) entities, which include 
User Agents, Proxy servers, Redirect servers and Registrars.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ietf-sip-mib-07.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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mpierce1 | 4 Aug 2003 19:23
Picon
Favicon

Re: draft-ietf-resource-priority-01 draft

Comments as follows:

1. Number of priority values

There continues to be a problem with the possible number of priority values per namespace. Since the whole purpose of this header to provide priority for one call over another, there must be, at a minimum, two values registered per namespace.

The IANA considerations states that: "The registration MUST indicate the default level to be assumed in the absence of the priority value or if the implementation does not understand a level from the namespace." This necessitates the registration of a "normal" level (to be the default) in order to be able to assign an "elevated" level. A namespace can not contain only one value.

Section 3 states "Each namespace has at least one priority value." and "We require that even namespaces with only one priority value list that value to avoid problems ..."

If the change proposed above to require multiple levels is made, the above statement ("We require...") can be deleted.  Otherwise, it needs to be modified, since it isn't clear whether it is intended to refer to the IANA considerations or the contents of the Resource-Priority header. If the former, it should be moved to Section 12 and state that "Namespaces with only one priority value MUST register that value to avoid problems if additional priority values are added later". If the latter, it should state: "If a namespace only contains one priority value, that value SHOULD still be included in a Resource-Priority header to avoid problems if additional priority values are added later."

2. Number of headers

There is also a confusion about the number of R-P headers which may be included. While 4.5 correctly states that "The UAC MUST only include at most one Resource-Priority header field in the request.", Section 3 includes the statement that "There may be multiple resource values or, equivalently, multiple Resource-Priority header fields." (which is followed by the example of the US Wireless Priority System). It isn't clear how to interpret this example, since it refers to possible namespaces and priorities which aren't defined in this document. I suggest that these two paragraphs be deleted. Other text already indicates that an R-P header can contain multiple namespaces but not multiple values per namespace.

3. References to ETS

The reference to "Emergency Telecommunications Systems (ETS)" in 8.2 should be changed, since the headers defined in this document apply to more than what is commonly called "ETS". The three namespaces defined in Annex B are not a part of "ETS".

The first sentence further states that ETS "must be protected from intercept and alteration" (lower case "must"). It isn't clear whether this was intended as a normative "MUST", or simply a statement that confidentiality and integrity are good things to have. Since requirements for this are distinct from the requirements for the Resource-Priority header, this statement should be corrected to not imply that this is a requirement. (In some cases, a call using the R-P header is not required to have confidentiality.) I would suggest wording this first sentence as "Calls which use elevated priority levels provided by the Resource-Priority header are likely to be sensitive and often need to be protected ..."

Likewise, Section 8.4 should be reworded to "As noted, systems which use the Resource-Priority header are likely to be subject ..."

4. IANA Considerations

The final paragraph under IANA Consideration in Section 12 states:

"Namespaces MAY also impose particular authentication or authorization consideration that are stricter than the baseline described here."

This implies that this is a part of the IANA registration, that is, that it is specified when registering a namespace. Since this should be a local matter and not a part of registration, it should not be stated here but moved to the end of Section 8.1.

Mike Pierce
Permalink | Reply | 1 comment |
headers
Gunn, Janet | 4 Aug 2003 23:54

RE: draft-ietf-resource-priority-01 draft

I am a little confused by this paragraph in section 2 (immediately after the
enumeration of the ways in which the resource priority header can be used).

  "This header field is related to, but differs in semantics from, the
   Priority header field (RFC 3261 [2], Section 20.26).  The Priority
   header field describes the priority that the SIP request should have
   to the receiving human or its agent. For example, it may be factored
   into decisions about call routing and acceptance.  While it does not
   directly influence the forwarding behavior of IP routers or the use
   of communications resources such as packet forwarding priority,
   procedures for using this header to cause such influence may be
   defined in other documents."

Does the "it" in the third and fourth refer to the "Resource Priority
Header" or the "Priority Header"?  Logically, it would seem to mean the RPH
(in the fourth sentence, if not the third).  But syntactically, it seems to
mean the PH.

I think it is just an editing nit.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 0 comments |
headers
Mark Watson | 6 Aug 2003 14:55

RE: draft-ietf-resource-priority-01 draft

Henning,

It may not have been intentional, but I read a slight implication in the draft that the authorisation decision (whether a method should be afforded the priority requested) was based just on the identity of the caller.

I think it would be useful to clarify somewhere that other things may be taken into account as well, such as the requested destination.

Regards...Mark

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs <at> cs.columbia.edu]
Sent: 28 July 2003 19:10
To: sip <at> ietf.org
Subject: [Sip] draft-ietf-resource-priority-01 draft


The revised version of the draft, based on discussions in Vienna, is now
in the archives. I would appreciate comments

http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-01.txt

Thanks.

Henning


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

Permalink | Reply | 0 comments |
headers
Ranjit Avasarala | 6 Aug 2003 15:21

Sip unicode support


Hi
    How to support unicode in SIP? My requirement is to support Japanese
/ korean characters using unicode

Thanks
Ranjit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 1 comment |
headers
Christian Stredicke | 6 Aug 2003 15:33
Picon
Favicon

AW: Sip unicode support

Just use UTF-8 for example in the display-name. The character set of URL
is limited as indicated in the RFC 3261.

CS

> -----Ursprüngliche Nachricht-----
> Von: sip-admin <at> ietf.org [mailto:sip-admin <at> ietf.org] Im Auftrag von
Ranjit
> Avasarala
> Gesendet: Mittwoch, 6. August 2003 15:22
> An: sip <at> ietf.org
> Cc: sip-implementors <at> cs.columbia.edu
> Betreff: [Sip] Sip unicode support
> 
> 
> 
> Hi
>     How to support unicode in SIP? My requirement is to support
Japanese
> / korean characters using unicode
> 
> Thanks
> Ranjit
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sipping <at> ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 0 comments |
headers
Carlos Becker Westphall | 6 Aug 2003 15:23
Picon

NOMS 2004 - Nine days to the Deadline - 15th August 2003

***** Paper submission deadline extended to Friday 15th August 2003 *****

        Network Operation & Management Symposium 2004 

"Managing Next Generation Convergence Networks and Services"

                Seoul Korea, 19-23, April 2004

See < http://www.noms2004.org/> for latest information

The 9th IEEE/IFIP Network Operations and Management Symposium (NOMS 2004)
will be held 19-23 April, 2004 at Seoul, Korea. Held in the even-numbered
years since 1988, NOMS 2004 will continue the established tradition of
NOMS and IM as the primary forum for technical exchange of research,
standards, development, systems integrator, service providers, and user
communities. NOMS 2004 will present the latest approaches and technical
solutions in the area of network operations and management. An exciting,
peer-reviewed program of technical sessions, tutorials, posters, panels
and vendor exhibits will address the ever-increasing interest in overall
management solutions for all types of communications and computing
networks, systems, services and enterprise applications.

The concept of network convergence has recently emerged as a new attempt
for the merging of telephony and data networks into a single,
multi-service network exploiting the ubiquity of the Internet Protocol.
For this increasingly attractive business model, in both wired and
wireless domains, strategic research is required to devise the best
integration architectures, operations and management solutions. This
creates a unique opportunity for the network operation and management
community to respond to the ever-increasing demand for network resilience,
security, quality-of-service and mobility management at unprecedented
scales. The NOMS 2004 provides the forum for discussing these research
challenges and many others inherent to the integrated management of next
generation converged networks and services.

This year NOMS 2004 will broaden the scope of previous IM and NOMS by
expanding its program to include a broader set of topics ranging from
network operation and management to network planning, service engineering
and business processes for network and service management. Special
attention will be given to experiences that emphasize lessons learned and
reports on practice from industry. Authors are invited to submit complete
unpublished papers, which are not under review in any other conference or
journal. Authors are also invited to submit proposals for tutorials, panel
discussions, poster demonstrations, or birds-of-a-feather sessions.

Important Dates:
Deadline  for  Submitting  Papers: 15  August   2003
Deadline  for  Tutorials, Panels and  Posters:  1 October  2003
Notification of Acceptance:15 November 2003
Deadline for Submitting Revised Papers:15 December 2003

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
Permalink | Reply | 0 comments |
headers
Robert Sparks | 6 Aug 2003 19:14

WGLC summary : Referred-by

I've revised Referred-By based on the comments received
during WGLC. 

I incorporated all of Mary's suggestions except for reducing the
strength of rejecting requests with invalid tokens from MUST to SHOULD.
She and I were the only people to comment on the issue, so I left it
the way it it had been. 

The updated draft can be retrieved from 
http://www.nostrum.com/~rjsparks/draft-ietf-sip-referredby-03.txt
until it appears in the repository.

I believe this is ready to send to the IESG.

RjS

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 2 comments |
headers
Internet-Drafts | 7 Aug 2003 13:52
Picon
Favicon

I-D ACTION:draft-ietf-sip-referredby-03.txt

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

	Title		: The SIP Referred-By Mechanism
	Author(s)	: R. Sparks
	Filename	: draft-ietf-sip-referredby-03.txt
	Pages		: 25
	Date		: 2003-8-6
	
The SIP REFER method [2] provides a mechanism where one party (the
referrer) gives a second party (the referree) an arbitrary URI to
reference.  If that URI is a SIP URI, the referree will send a SIP
request, often an INVITE, to that URI (the refer target).  This
document extends the REFER method allowing the referrer to provide
information about the reference to the refer target using the
referree as an intermediary.  This information includes the identity
of the referrer and the URI to which the referrer referred.  The
mechanism utilizes S/MIME to help protect this information from a
malicious intermediary.  This protection is optional, but a recipient
may refuse to accept a request unless it is present.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ietf-sip-referredby-03.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-ietf-sip-referredby-03.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.
Attachment: message/external-body, 137 bytes
Attachment (draft-ietf-sip-referredby-03.txt): message/external-body, 67 bytes
Permalink | Reply | 0 comments |

Gmane