From rjsparks@nostrum.com Tue Feb 7 10:22:11 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C6721F8891 for ; Tue, 7 Feb 2012 10:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cATnWb7kwbbi for ; Tue, 7 Feb 2012 10:22:04 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E658F21F8881 for ; Tue, 7 Feb 2012 10:22:03 -0800 (PST) Received: from unexplicable.local (pool-173-57-95-103.dllstx.fios.verizon.net [173.57.95.103]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q17IM2Ux085551 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 7 Feb 2012 12:22:02 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F316BCA.5070302@nostrum.com> Date: Tue, 07 Feb 2012 12:22:02 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rai@ietf.org References: <20120207173910.EC68621F87DB@ietfa.amsl.com> In-Reply-To: <20120207173910.EC68621F87DB@ietfa.amsl.com> X-Forwarded-Message-Id: <20120207173910.EC68621F87DB@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000606070302090109000708" Received-SPF: pass (nostrum.com: 173.57.95.103 is authenticated by a trusted mechanism) Subject: [RAI] Fwd: [BLISS] WG Review: Recharter of Basic Level of Interoperability for SIP Services (bliss) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 18:22:12 -0000 This is a multi-part message in MIME format. --------------000606070302090109000708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: [BLISS] WG Review: Recharter of Basic Level of Interoperability for SIP Services (bliss) Date: Tue, 7 Feb 2012 09:39:10 -0800 (PST) From: IESG Secretary Reply-To: iesg@ietf.org To: IETF Announcement list CC: bliss@ietf.org A modified charter has been submitted for the Basic Level of Interoperability for SIP Services (bliss) working group in the Real-Time Applications and Infrastructure Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, February 14, 2012. Basic Level of Interoperability for SIP Services (bliss) ----------------------------------------- Status: Active Working Group Last Updated: 2012-02-02 Chair: Shida Schubert Real-Time Applications and Infrastructure Area Director(s): Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Tech Advisor: Jonathan Rosenberg Mailing Lists: General Discussion: bliss@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bliss Archive: http://www.ietf.org/mail-archive/web/bliss Description of Working Group: The BLISS working group is rechartered to adjust its scope to reflect changes in working group interest and RAI processes since its original chartering. BLISS was chartered prior to the creation of DISPATCH. The charter called for the WG to document how to realize four initial building blocks in an interoperable way with existing standards, and to describe the use of those building blocks to implement specific call features. Any extensions to the protocols beyond the creation of event packages or the addition of SIP URI parameters was set out of scope for this working group. Working group interest in all but two of those building blocks has diminished. The current drafts on those two propose extensions that under the original charter would need to be developed in other working groups. Given the update to the SIP change process (RFC5727) and the subsequent restructuring of the RAI area, these constraints are being revised as detailed below. The BLISS working group shall be closed after completing the following two proposed standards: - call completion with queuing as proposed in draft-ietf-bliss-call-completion - shared appearances as proposed in draft-ietf-bliss-shared-appearances The goal to produce a problem statement and a common template for describing primitives is abandoned. The group will continue to work within the constraints of the creation of event packages and SIP URI parameters, with the addition of the ability to - exercise the already standardized extension points of SIP header fields. Currently, the documents propose to extend the SIP Alert-Info header field (RFC3261) to carry an appearance identifier, and the SIP Call-Info header field (RFC3261) to carry a call completion indicator. - extend the SIP Dialog event package (RFC4235) to carry appearance related state, The working group will coordinate review of those extensions with the SIPCORE working group. Describing the security properties (particularly any privacy considerations) of these deliverables remains of special importance. Upon completion of these two work items, the working group will conclude. Future proposals should be directed to the DISPATCH working group. Goals and Milestones: Mar 2012 Submit Shared Appearances to the IESG for publication as Proposed Standard Jul 2012 Submit Call Completion to the IESG for publication as Proposed Standard Sep 2012 Bliss concludes _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss --------------000606070302090109000708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI

-------- Original Message --------
Subject: [BLISS] WG Review: Recharter of Basic Level of Interoperability for SIP Services (bliss)
Date: Tue, 7 Feb 2012 09:39:10 -0800 (PST)
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: iesg@ietf.org
To: IETF Announcement list <ietf-announce@ietf.org>
CC: bliss@ietf.org 


A modified charter has been submitted for the Basic Level of 
Interoperability for SIP Services (bliss) working group in the Real-Time 
Applications and Infrastructure Area of the IETF.  The IESG has not made 
any determination as yet.  The modified charter is provided below for 
informational purposes only.  Please send your comments to the IESG 
mailing list (iesg@ietf.org) by Tuesday, February 14, 2012.

Basic Level of Interoperability for SIP Services (bliss)
-----------------------------------------
Status: Active Working Group
Last Updated: 2012-02-02

Chair:
 Shida Schubert <shida@ntt-at.com>

Real-Time Applications and Infrastructure Area Director(s):
 Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
 Robert Sparks <rjsparks@nostrum.com>

Real-Time Applications and Infrastructure Area Advisor:
 Robert Sparks <rjsparks@nostrum.com>

Tech Advisor: 
  Jonathan Rosenberg <jdrosen@cisco.com>

Mailing Lists:
 General Discussion: bliss@ietf.org
 To Subscribe:	https://www.ietf.org/mailman/listinfo/bliss
 Archive:	http://www.ietf.org/mail-archive/web/bliss

Description of Working Group:

The BLISS working group is rechartered to adjust
its scope to reflect changes in working group interest
and RAI processes since its original chartering.

BLISS was chartered prior to the creation of DISPATCH.
The charter called for the WG to document how to realize
four initial building blocks in an interoperable way with
existing standards, and to describe the use of those building
blocks to implement specific call features. Any extensions
to the protocols beyond the creation of event packages or
the addition of SIP URI parameters was set out of scope
for this working group.

Working group interest in all but two of those building
blocks has diminished.  The current drafts on those two
propose extensions that under the original charter would
need to be developed in other working groups. Given the
update to the SIP change process (RFC5727) and the
subsequent restructuring of the RAI area, these constraints
are being revised as detailed below.

The BLISS working group shall be closed after completing
the following two proposed standards:
 - call completion with queuing as proposed in
     draft-ietf-bliss-call-completion
 - shared appearances as proposed in
     draft-ietf-bliss-shared-appearances

The goal to produce a problem statement and a
common template for describing primitives is abandoned.

The group will continue to work within the constraints of
the creation of event packages and SIP URI parameters, with
the addition of the ability to

 - exercise the already standardized extension points of
   SIP header fields. Currently, the documents propose to
   extend the SIP Alert-Info header field (RFC3261) to carry
   an appearance identifier, and the SIP Call-Info header
   field (RFC3261) to carry a call completion indicator.

 - extend the SIP Dialog event package (RFC4235) to carry
   appearance related state,

The working group will coordinate review of those extensions
with the SIPCORE working group.

Describing the security properties (particularly any privacy
considerations) of these deliverables remains of special
importance.

Upon completion of these two work items, the working group
will conclude. Future proposals should be directed to the
DISPATCH working group.

Goals and Milestones:

Mar 2012  Submit Shared Appearances to the IESG for
          publication as Proposed Standard
Jul 2012  Submit Call Completion to the IESG for
          publication as Proposed Standard
Sep 2012  Bliss concludes
_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss
--------------000606070302090109000708-- From gonzalo.camarillo@ericsson.com Tue Feb 7 12:32:52 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F9221F8734 for ; Tue, 7 Feb 2012 12:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.922 X-Spam-Level: X-Spam-Status: No, score=-109.922 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gvjul3OHWsR9 for ; Tue, 7 Feb 2012 12:32:52 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C45FA21F86AD for ; Tue, 7 Feb 2012 12:32:49 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-7a-4f318a704ea1 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 90.57.02613.07A813F4; Tue, 7 Feb 2012 21:32:48 +0100 (CET) Received: from [131.160.126.146] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 7 Feb 2012 21:32:47 +0100 Message-ID: <4F318A6F.5030307@ericsson.com> Date: Tue, 7 Feb 2012 22:32:47 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rai@ietf.org References: <4F318A59.5020700@ericsson.com> In-Reply-To: <4F318A59.5020700@ericsson.com> X-Enigmail-Version: 1.3.4 X-Forwarded-Message-Id: <4F318A59.5020700@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [RAI] Fwd: SDP directorate created X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 20:32:52 -0000 FYI. Gonzalo -------- Original Message -------- Subject: SDP directorate created Date: Tue, 07 Feb 2012 22:32:25 +0200 From: Gonzalo Camarillo To: mmusic Folks, per our discussions regarding SDP extension coordination, we have created an SDP directorate, which includes SDP experts that will review proposals for SDP extensions when needed. http://www.ietf.org/iesg/directorate/sdp.html Cheers, Gonzalo From kpfleming@digium.com Wed Feb 8 15:04:06 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C007811E807F for ; Wed, 8 Feb 2012 15:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyrGZBRa2wlG for ; Wed, 8 Feb 2012 15:04:05 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id AB61E21F8562 for ; Wed, 8 Feb 2012 15:04:05 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RvGYX-0006vn-0G for rai@ietf.org; Wed, 08 Feb 2012 17:04:05 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 034B8D8006 for ; Wed, 8 Feb 2012 17:04:05 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWA11uzc+aEo for ; Wed, 8 Feb 2012 17:04:04 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 777FAD8005 for ; Wed, 8 Feb 2012 17:04:04 -0600 (CST) Message-ID: <4F32FF63.80505@digium.com> Date: Wed, 08 Feb 2012 17:04:03 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: rai@ietf.org References: <4F318A59.5020700@ericsson.com> <4F318A6F.5030307@ericsson.com> In-Reply-To: <4F318A6F.5030307@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [RAI] Fwd: SDP directorate created X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 23:04:06 -0000 On 02/07/2012 02:32 PM, Gonzalo Camarillo wrote: > FYI. > > Gonzalo > > -------- Original Message -------- > Subject: SDP directorate created > Date: Tue, 07 Feb 2012 22:32:25 +0200 > From: Gonzalo Camarillo > To: mmusic > > Folks, > > per our discussions regarding SDP extension coordination, we have > created an SDP directorate, which includes SDP experts that will review > proposals for SDP extensions when needed. > > http://www.ietf.org/iesg/directorate/sdp.html Excellent news! -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From rjsparks@nostrum.com Tue Feb 14 14:36:07 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B2321E8112; Tue, 14 Feb 2012 14:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UyUIQgmE1Cy; Tue, 14 Feb 2012 14:36:06 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D72C21E8016; Tue, 14 Feb 2012 14:36:06 -0800 (PST) Received: from unexplicable.local (pool-71-170-125-181.dllstx.fios.verizon.net [71.170.125.181]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q1EMa57P092767 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 16:36:05 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F3AE1D5.5030505@nostrum.com> Date: Tue, 14 Feb 2012 16:36:05 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rai@ietf.org, simple@ietf.org, geopriv@ietf.org References: <20120214215439.F2F5172F1F1@rfc-editor.org> In-Reply-To: <20120214215439.F2F5172F1F1@rfc-editor.org> X-Forwarded-Message-Id: <20120214215439.F2F5172F1F1@rfc-editor.org> Content-Type: multipart/mixed; boundary="------------010003050509010204040407" Received-SPF: pass (nostrum.com: 71.170.125.181 is authenticated by a trusted mechanism) Subject: [RAI] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rai@ietf.org List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:36:07 -0000 This is a multi-part message in MIME format. --------------010003050509010204040407 Content-Type: multipart/alternative; boundary="------------000804020103070702030009" --------------000804020103070702030009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This erratum will change the schema for RPID registered with IANA. (I've confirmed with IANA that they can handle a change made this way). There have been discussions in several groups about registry maintenance with some confusion about whether changes can be made to an existing schema. Our XML experts (Peter in this case) assure us that schema changes are OK. In most cases, I would ask that a change to a registration like this be done with a document. That's definitely required if we're doing anything more than correcting an obvious mistake. In this case, however, it is obvious that these values were intended to be included in the affected list from the beginning. I plan to approve this erratum a week from today. If you believe this is not the right thing to do, please speak now. RjS -------- Original Message -------- Subject: [Technical Errata Reported] RFC4480 (3121) Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST) From: RFC Errata System To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com CC: stpeter@stpeter.im, simple@ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC4480, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121 -------------------------------------- Type: Technical Reported by: Peter Saint-Andre Section: 7.2 Original Text ------------- Corrected Text -------------- Notes ----- Erratum #2959 claimed that the element "lunch" needs to be removed from the specification since it is not included in the schema. However, the schema was in error. This erratum corrects the schema so that, if approved, IANA can update the information at http://www.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4480 (draft-ietf-simple-rpid-10) -------------------------------------- Title : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) Publication Date : July 2006 Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG --------------000804020103070702030009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This erratum will change the schema for RPID registered with IANA.
(I've confirmed with IANA that they can handle a change made this way).

There have been discussions in several groups about registry maintenance with some
confusion about whether changes can be made to an existing schema. Our XML experts
(Peter in this case) assure us that schema changes are OK.

In most cases, I would ask that a change to a registration like this be done with a document.
That's definitely required if we're doing anything more than correcting an obvious mistake.
In this case, however, it is obvious that these values were intended to be included in the
affected list from the beginning.

I plan to approve this erratum a week from today. If you believe this is not the right thing to do,
please speak now.

RjS


-------- Original Message --------
Subject: [Technical Errata Reported] RFC4480 (3121)
Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST)
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com
CC: stpeter@stpeter.im, simple@ietf.org, rfc-editor@rfc-editor.org 


The following errata report has been submitted for RFC4480,
"RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121

--------------------------------------
Type: Technical
Reported by: Peter Saint-Andre <stpeter@stpeter.im>

Section: 7.2

Original Text
-------------
                 <xs:element name="looking-for-work"
                   type="empty" />
                 <xs:element name="meal"
                   type="empty" />

Corrected Text
--------------
                 <xs:element name="looking-for-work"
                   type="empty" />
                 <xs:element name="lunch"
                   type="empty" />
                 <xs:element name="meal"
                   type="empty" />

Notes
-----
Erratum #2959 claimed that the element "lunch" needs to be removed from the specification since it is not included in the schema. However, the schema was in error. This erratum corrects the schema so that, if approved, IANA can update the information at http://www.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4480 (draft-ietf-simple-rpid-10)
--------------------------------------
Title               : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
Publication Date    : July 2006
Author(s)           : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg
Category            : PROPOSED STANDARD
Source              : SIP for Instant Messaging and Presence Leveraging Extensions
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
--------------000804020103070702030009-- --------------010003050509010204040407 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------010003050509010204040407-- From ben@nostrum.com Tue Feb 14 14:38:51 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D598421F8567; Tue, 14 Feb 2012 14:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vdmoq3u3iM9; Tue, 14 Feb 2012 14:38:50 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D03C621F8564; Tue, 14 Feb 2012 14:38:48 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q1EMclFV092966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Feb 2012 16:38:47 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_557CE07C-4775-46A4-AA9B-8E24EF1BF16F" From: Ben Campbell In-Reply-To: <4F3AE1D5.5030505@nostrum.com> Date: Tue, 14 Feb 2012 16:38:50 -0600 Message-Id: References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> To: rai@ietf.org X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: geopriv@ietf.org, simple@ietf.org Subject: Re: [RAI] [Simple] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:38:52 -0000 --Apple-Mail=_557CE07C-4775-46A4-AA9B-8E24EF1BF16F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 14, 2012, at 4:36 PM, Robert Sparks wrote: > This erratum will change the schema for RPID registered with IANA.=20 > (I've confirmed with IANA that they can handle a change made this = way). >=20 > There have been discussions in several groups about registry = maintenance with some > confusion about whether changes can be made to an existing schema. Our = XML experts > (Peter in this case) assure us that schema changes are OK. >=20 > In most cases, I would ask that a change to a registration like this = be done with a document. > That's definitely required if we're doing anything more than = correcting an obvious mistake. > In this case, however, it is obvious that these values were intended = to be included in the=20 > affected list from the beginning. >=20 > I plan to approve this erratum a week from today. If you believe this = is not the right thing to do, > please speak now. >=20 While you didn't ask for concurring opinions: I concur with the = approach. > RjS >=20 >=20 > -------- Original Message -------- > Subject: [Technical Errata Reported] RFC4480 (3121) > Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST) > From: RFC Errata System > To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, = jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, = ben@nostrum.com, hisham.khartabil@gmail.com > CC: stpeter@stpeter.im, simple@ietf.org, rfc-editor@rfc-editor.org >=20 > The following errata report has been submitted for RFC4480, > "RPID: Rich Presence Extensions to the Presence Information Data = Format (PIDF)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4480&eid=3D3121 >=20 > -------------------------------------- > Type: Technical > Reported by: Peter Saint-Andre >=20 > Section: 7.2 >=20 > Original Text > ------------- > type=3D"empty" /> > type=3D"empty" /> >=20 > Corrected Text > -------------- > type=3D"empty" /> > type=3D"empty" /> > type=3D"empty" /> >=20 > Notes > ----- > Erratum #2959 claimed that the element "lunch" needs to be removed = from the specification since it is not included in the schema. However, = the schema was in error. This erratum corrects the schema so that, if = approved, IANA can update the information at = http://www.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4480 (draft-ietf-simple-rpid-10) > -------------------------------------- > Title : RPID: Rich Presence Extensions to the Presence = Information Data Format (PIDF) > Publication Date : July 2006 > Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. = Rosenberg > Category : PROPOSED STANDARD > Source : SIP for Instant Messaging and Presence = Leveraging Extensions > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail=_557CE07C-4775-46A4-AA9B-8E24EF1BF16F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Feb 14, 2012, at 4:36 PM, Robert Sparks wrote:

This erratum will change the schema for RPID registered with IANA.
(I've confirmed with IANA that they can handle a change made this way).

There have been discussions in several groups about registry maintenance with some
confusion about whether changes can be made to an existing schema. Our XML experts
(Peter in this case) assure us that schema changes are OK.

In most cases, I would ask that a change to a registration like this be done with a document.
That's definitely required if we're doing anything more than correcting an obvious mistake.
In this case, however, it is obvious that these values were intended to be included in the
affected list from the beginning.

I plan to approve this erratum a week from today. If you believe this is not the right thing to do,
please speak now.


While you didn't ask for concurring opinions: I concur with the approach.


RjS


-------- Original Message --------
Subject: [Technical Errata Reported] RFC4480 (3121)
Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST)
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com
CC: stpeter@stpeter.im, simple@ietf.org, rfc-editor@rfc-editor.org 


The following errata report has been submitted for RFC4480,
"RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121

--------------------------------------
Type: Technical
Reported by: Peter Saint-Andre <stpeter@stpeter.im>

Section: 7.2

Original Text
-------------
                 <xs:element name="looking-for-work"
                   type="empty" />
                 <xs:element name="meal"
                   type="empty" />

Corrected Text
--------------
                 <xs:element name="looking-for-work"
                   type="empty" />
                 <xs:element name="lunch"
                   type="empty" />
                 <xs:element name="meal"
                   type="empty" />

Notes
-----
Erratum #2959 claimed that the element "lunch" needs to be removed from the specification since it is not included in the schema. However, the schema was in error. This erratum corrects the schema so that, if approved, IANA can update the information at http://www.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4480 (draft-ietf-simple-rpid-10)
--------------------------------------
Title               : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
Publication Date    : July 2006
Author(s)           : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg
Category            : PROPOSED STANDARD
Source              : SIP for Instant Messaging and Presence Leveraging Extensions
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
<Attached Message Part.txt>_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

--Apple-Mail=_557CE07C-4775-46A4-AA9B-8E24EF1BF16F-- From martin.thomson@gmail.com Tue Feb 14 15:08:55 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6CD21E80F5; Tue, 14 Feb 2012 15:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.892 X-Spam-Level: X-Spam-Status: No, score=-4.892 tagged_above=-999 required=5 tests=[AWL=-1.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwvvMBwbgMlP; Tue, 14 Feb 2012 15:08:54 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A370121E807F; Tue, 14 Feb 2012 15:08:51 -0800 (PST) Received: by bkuw12 with SMTP id w12so493107bku.31 for ; Tue, 14 Feb 2012 15:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PMxLIOSJXivwnja022a0GZ2F6Vje4w22ubo4ljwpSzI=; b=klaxe4Qi8zO56z1SwK3vaTt8aQq/UYpwvtCxhlzU2VYJfZwGIMHuNkRuFDzwB4lGbe 0LdmO8F3H8urP9bhmm2h1iU085UZnmJoLpv6filS9NL+2HvosTdzEs7RTcvmL5DLVe15 4lwDe/VzhAMOD+F+sXF8rtsFYKBj76pw6F/Ww= MIME-Version: 1.0 Received: by 10.204.141.9 with SMTP id k9mr10167291bku.93.1329260930673; Tue, 14 Feb 2012 15:08:50 -0800 (PST) Received: by 10.204.241.81 with HTTP; Tue, 14 Feb 2012 15:08:50 -0800 (PST) In-Reply-To: <4F3AE1D5.5030505@nostrum.com> References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> Date: Tue, 14 Feb 2012 15:08:50 -0800 Message-ID: From: Martin Thomson To: rai@ietf.org Content-Type: multipart/alternative; boundary=0015175d6826962bcf04b8f4ad31 Cc: geopriv@ietf.org, simple@ietf.org, Peter Saint-Andre Subject: Re: [RAI] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 23:08:55 -0000 --0015175d6826962bcf04b8f4ad31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Since the extension point in the existing schema is marked ##other and lax, a processor with an old schema will reject an instance document that contains the "unknown" {urn:ietf:params:xml:ns:pidf:rpid}:lunch element. That's a backwards compatibility break. --Martin On 14 February 2012 14:36, Robert Sparks wrote: > This erratum will change the schema for RPID registered with IANA. > (I've confirmed with IANA that they can handle a change made this way). > > There have been discussions in several groups about registry maintenance > with some > confusion about whether changes can be made to an existing schema. Our XM= L > experts > (Peter in this case) assure us that schema changes are OK. > > In most cases, I would ask that a change to a registration like this be > done with a document. > That's definitely required if we're doing anything more than correcting a= n > obvious mistake. > In this case, however, it is obvious that these values were intended to b= e > included in the > affected list from the beginning. > > I plan to approve this erratum a week from today. If you believe this is > not the right thing to do, > please speak now. > > RjS > > > -------- Original Message -------- Subject: [Technical Errata Reported] > RFC4480 (3121) Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST) From: RFC > Errata System To= : > hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, > jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, > ben@nostrum.com, hisham.khartabil@gmail.com CC: stpeter@stpeter.im, > simple@ietf.org, rfc-editor@rfc-editor.org > > The following errata report has been submitted for RFC4480, > "RPID: Rich Presence Extensions to the Presence Information Data Format (= PIDF)". > > -------------------------------------- > You may review the report below and at:http://www.rfc-editor.org/errata_s= earch.php?rfc=3D4480&eid=3D3121 > > -------------------------------------- > Type: Technical > Reported by: Peter Saint-Andre > > Section: 7.2 > > Original Text > ------------- > type=3D"empty" /> > type=3D"empty" /> > > Corrected Text > -------------- > type=3D"empty" /> > type=3D"empty" /> > type=3D"empty" /> > > Notes > ----- > Erratum #2959 claimed that the element "lunch" needs to be removed from t= he specification since it is not included in the schema. However, the schem= a was in error. This erratum corrects the schema so that, if approved, IANA= can update the information at http://www.iana.org/assignments/xml-registry= /schema/pidf/status/rpid.xsd > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4480 (draft-ietf-simple-rpid-10) > -------------------------------------- > Title : RPID: Rich Presence Extensions to the Presence Info= rmation Data Format (PIDF) > Publication Date : July 2006 > Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenber= g > Category : PROPOSED STANDARD > Source : SIP for Instant Messaging and Presence Leveraging E= xtensions > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > > --0015175d6826962bcf04b8f4ad31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Since the extension point in the existing schema is marked ##other and lax,= a processor with an old schema will reject an instance document that conta= ins the "unknown" {urn:ietf:params:xml:ns:pidf:rpid}:lunch elemen= t.

That's a backwards compatibility break.

--Martin

On 1= 4 February 2012 14:36, Robert Sparks <rjsparks@nostrum.com> wrote:
=20 =20 =20
This erratum will change the schema for RPID registered with IANA.
(I've confirmed with IANA that they can handle a change made this way).

There have been discussions in several groups about registry maintenance with some
confusion about whether changes can be made to an existing schema. Our XML experts
(Peter in this case) assure us that schema changes are OK.

In most cases, I would ask that a change to a registration like this be done with a document.
That's definitely required if we're doing anything more than correcting an obvious mistake.
In this case, however, it is obvious that these values were intended to be included in the
affected list from the beginning.

I plan to approve this erratum a week from today. If you believe this is not the right thing to do,
please speak now.

RjS


-------- Original Message --------
Subject: [Technical Errata Reported] RFC4480 (3121)
Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST)
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyziva= t@cisco.com, jdr= osen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostru= m.com, = hisham.khartabil@gmail.com
CC: stpet= er@stpeter.im, sim= ple@ietf.org, = rfc-editor@rfc-editor.org 


The following errata report has been submitted for RFC4480,
"RPID: Rich Presence Extensions to the Presence Information Data Forma=
t (PIDF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=
=3D4480&eid=3D3121

--------------------------------------
Type: Technical
Reported by: Peter Saint-Andre <stpeter@stpeter.im>

Section: 7.2

Original Text
-------------
                 <xs:element name=3D"looking-for-work"
                   type=3D"empty" />
                 <xs:element name=3D"meal"
                   type=3D"empty" />

Corrected Text
--------------
                 <xs:element name=3D"looking-for-work"
                   type=3D"empty" />
                 <xs:element name=3D"lunch"
                   type=3D"empty" />
                 <xs:element name=3D"meal"
                   type=3D"empty" />

Notes
-----
Erratum #2959 claimed that the element "lunch" needs to be remove=
d from the specification since it is not included in the schema. However, t=
he schema was in error. This erratum corrects the schema so that, if approv=
ed, IANA can update the information at http://w=
ww.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea=
se
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.=20

--------------------------------------
RFC4480 (draft-ietf-simple-rpid-10)
--------------------------------------
Title               : RPID: Rich Presence Extensions to the Presence Inform=
ation Data Format (PIDF)
Publication Date    : July 2006
Author(s)           : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg
Category            : PROPOSED STANDARD
Source              : SIP for Instant Messaging and Presence Leveraging Ext=
ensions
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv


--0015175d6826962bcf04b8f4ad31-- From gonzalo.camarillo@ericsson.com Thu Feb 16 00:01:23 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA5E21E8013 for ; Thu, 16 Feb 2012 00:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.111 X-Spam-Level: X-Spam-Status: No, score=-110.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F4aMDIxL3aD for ; Thu, 16 Feb 2012 00:01:19 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 37D0621E8017 for ; Thu, 16 Feb 2012 00:01:19 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-48-4f3cb7ceeb38 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EE.4E.01970.EC7BC3F4; Thu, 16 Feb 2012 09:01:18 +0100 (CET) Received: from [131.160.126.198] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Thu, 16 Feb 2012 09:01:17 +0100 Message-ID: <4F3CB7CD.7030703@ericsson.com> Date: Thu, 16 Feb 2012 10:01:17 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "rai@ietf.org" References: <4F318A59.5020700@ericsson.com> <4F318A6F.5030307@ericsson.com> In-Reply-To: <4F318A6F.5030307@ericsson.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [RAI] Fwd: SDP directorate created X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 08:01:23 -0000 Hi, FYI: related to this, we are going to inform relevant standards organizations about the creation of this SDP directorate so that they can get their SDP extensions reviewed early in their development. Cheers, Gonzalo On 07/02/2012 10:32 PM, Gonzalo Camarillo wrote: > FYI. > > Gonzalo > > -------- Original Message -------- > Subject: SDP directorate created > Date: Tue, 07 Feb 2012 22:32:25 +0200 > From: Gonzalo Camarillo > To: mmusic > > Folks, > > per our discussions regarding SDP extension coordination, we have > created an SDP directorate, which includes SDP experts that will review > proposals for SDP extensions when needed. > > http://www.ietf.org/iesg/directorate/sdp.html > > Cheers, > > Gonzalo > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai > From stpeter@stpeter.im Thu Feb 16 09:58:30 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9946221F87D3; Thu, 16 Feb 2012 09:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s+yoilypi3k; Thu, 16 Feb 2012 09:58:26 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1D75E21F87D8; Thu, 16 Feb 2012 09:58:25 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3AE6540058; Thu, 16 Feb 2012 11:09:20 -0700 (MST) Message-ID: <4F3D43C0.2040005@stpeter.im> Date: Thu, 16 Feb 2012 10:58:24 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Martin Thomson References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Feb 2012 10:16:51 -0800 Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org Subject: Re: [RAI] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:58:30 -0000 Naturally, it would make sense to check with current implementers. In particular, is anyone doing schema validation? On 2/14/12 4:08 PM, Martin Thomson wrote: > Since the extension point in the existing schema is marked ##other and > lax, a processor with an old schema will reject an instance document > that contains the "unknown" {urn:ietf:params:xml:ns:pidf:rpid}:lunch > element. > > That's a backwards compatibility break. > > --Martin > > On 14 February 2012 14:36, Robert Sparks > wrote: > > This erratum will change the schema for RPID registered with IANA. > (I've confirmed with IANA that they can handle a change made this way). > > There have been discussions in several groups about registry > maintenance with some > confusion about whether changes can be made to an existing schema. > Our XML experts > (Peter in this case) assure us that schema changes are OK. > > In most cases, I would ask that a change to a registration like this > be done with a document. > That's definitely required if we're doing anything more than > correcting an obvious mistake. > In this case, however, it is obvious that these values were intended > to be included in the > affected list from the beginning. > > I plan to approve this erratum a week from today. If you believe > this is not the right thing to do, > please speak now. > > RjS > > > -------- Original Message -------- > Subject: [Technical Errata Reported] RFC4480 (3121) > Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST) > From: RFC Errata System > > To: hgs+simple@cs.columbia.edu , > vkg@lucent.com , pkyzivat@cisco.com > , jdrosen@cisco.com > , gonzalo.camarillo@ericsson.com > , rjsparks@nostrum.com > , ben@nostrum.com > , hisham.khartabil@gmail.com > > CC: stpeter@stpeter.im , simple@ietf.org > , rfc-editor@rfc-editor.org > > > > > The following errata report has been submitted for RFC4480, > "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121 > > -------------------------------------- > Type: Technical > Reported by: Peter Saint-Andre > > Section: 7.2 > > Original Text > ------------- > type="empty" /> > type="empty" /> > > Corrected Text > -------------- > type="empty" /> > type="empty" /> > type="empty" /> > > Notes > ----- > Erratum #2959 claimed that the element "lunch" needs to be removed from the specification since it is not included in the schema. However, the schema was in error. This erratum corrects the schema so that, if approved, IANA can update the information at http://www.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4480 (draft-ietf-simple-rpid-10) > -------------------------------------- > Title : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) > Publication Date : July 2006 > Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg > Category : PROPOSED STANDARD > Source : SIP for Instant Messaging and Presence Leveraging Extensions > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From saul@ag-projects.com Thu Feb 16 10:11:59 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5FC21F87FD; Thu, 16 Feb 2012 10:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 226VFXmwQk5F; Thu, 16 Feb 2012 10:11:58 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB3A21F87F9; Thu, 16 Feb 2012 10:11:58 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id 215F7B01A4; Thu, 16 Feb 2012 19:11:56 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 75D31B01A2; Thu, 16 Feb 2012 19:11:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <4F3D43C0.2040005@stpeter.im> Date: Thu, 16 Feb 2012 19:11:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> <4F3D43C0.2040005@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 16 Feb 2012 10:16:51 -0800 Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org Subject: Re: [RAI] [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:11:59 -0000 Hi, On Feb 16, 2012, at 6:58 PM, Peter Saint-Andre wrote: > Naturally, it would make sense to check with current implementers. In > particular, is anyone doing schema validation? >=20 We are currently doing schema validation both on the server side = (OpenXCAP, for pidf-manipulation) and client side (SIPSIMPLE SDK). I didn't check the details of the errata, but if it's reasonable I guess = we could see if we can workaround it for a while and make the switch = after a reasonable amount of time. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From hannes.tschofenig@gmx.net Thu Feb 16 10:26:25 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4871D21F8666 for ; Thu, 16 Feb 2012 10:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IbjV0m8h2wS for ; Thu, 16 Feb 2012 10:26:21 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E173C21F863F for ; Thu, 16 Feb 2012 10:26:20 -0800 (PST) Received: (qmail invoked by alias); 16 Feb 2012 18:26:19 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp033) with SMTP; 16 Feb 2012 19:26:19 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+HmtAr5sKHdrVDCRjLy4ZoHJ/0E0Vc9LUvoQnYj4 x5CofKZL7x8cg/ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> Date: Thu, 16 Feb 2012 20:26:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> <4F3D43C0.2040005@stpeter.im> <088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org, Peter Saint-Andre Subject: Re: [RAI] [Geopriv] [Simple] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:26:25 -0000 I am curious: Why you do schema validation? When you receive a PIDF document in a SIP message then you will have to = parse it. Since we put any namespace=3D"##other" statements in nearly = all our schema files I am curious what you actually going to learn from = the validation since almost everything validates without error.=20 On Feb 16, 2012, at 8:11 PM, Sa=FAl Ibarra Corretg=E9 wrote: > Hi, >=20 > On Feb 16, 2012, at 6:58 PM, Peter Saint-Andre wrote: >=20 >> Naturally, it would make sense to check with current implementers. In >> particular, is anyone doing schema validation? >>=20 >=20 > We are currently doing schema validation both on the server side = (OpenXCAP, for pidf-manipulation) and client side (SIPSIMPLE SDK). >=20 > I didn't check the details of the errata, but if it's reasonable I = guess we could see if we can workaround it for a while and make the = switch after a reasonable amount of time. >=20 >=20 > Regards, >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From martin.thomson@gmail.com Thu Feb 16 11:38:57 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6491A21F8817; Thu, 16 Feb 2012 11:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.833 X-Spam-Level: X-Spam-Status: No, score=-4.833 tagged_above=-999 required=5 tests=[AWL=-1.234, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU0itTwN-xuA; Thu, 16 Feb 2012 11:38:56 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 449C721F8811; Thu, 16 Feb 2012 11:38:55 -0800 (PST) Received: by bkuw12 with SMTP id w12so2646704bku.31 for ; Thu, 16 Feb 2012 11:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L58NCRXHK4xHKh/cvZik0TxKzaDeL3sg/8T/vZP9W2E=; b=gDbcz3hIGat99HTHuA3gn7POFgGmj7wxglaQ5Uc3/p5q/vQnIRoSqDo1Vq4UQnjzNT ViqX4QaFsbu7z4OwUuUPzNKvI16hgYYcDlnI4u7gqG7F81asFeEUFojzcC6IxY/XzHh/ feoYq+vO1a/jqX60f/dqVU0TeTvmy/hc2PvxE= MIME-Version: 1.0 Received: by 10.205.125.12 with SMTP id gq12mr2493763bkc.39.1329421134354; Thu, 16 Feb 2012 11:38:54 -0800 (PST) Received: by 10.204.241.81 with HTTP; Thu, 16 Feb 2012 11:38:54 -0800 (PST) In-Reply-To: <4F3D43C0.2040005@stpeter.im> References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> <4F3D43C0.2040005@stpeter.im> Date: Thu, 16 Feb 2012 11:38:54 -0800 Message-ID: From: Martin Thomson To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org Subject: Re: [RAI] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:38:57 -0000 On 16 February 2012 09:58, Peter Saint-Andre wrote: > Naturally, it would make sense to check with current implementers. In > particular, is anyone doing schema validation? ...and who is using RPID? The intersection of those sets is probably small, possibly empty. And you want empty (or to exclude those who are willing to make a minor patch). I know that schema validation was the default mode of operation where I used to work. RPID was not. Sounds like more than an erratum's worth of work to me. Do you have a problem with noting the existence of the problem without specifying a remedy? From pp3129@att.com Fri Feb 17 08:48:44 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381D221E8075 for ; Fri, 17 Feb 2012 08:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1fUAgogG9Hu for ; Fri, 17 Feb 2012 08:48:43 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3564021E8039 for ; Fri, 17 Feb 2012 08:48:43 -0800 (PST) X-Env-Sender: pp3129@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1329497321!64058309!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22908 invoked from network); 17 Feb 2012 16:48:42 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-5.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Feb 2012 16:48:42 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1HGnAS8016734 for ; Fri, 17 Feb 2012 11:49:11 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1HGn6Ie016585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Feb 2012 11:49:06 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Fri, 17 Feb 2012 11:48:30 -0500 Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([169.254.5.149]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0355.002; Fri, 17 Feb 2012 11:48:30 -0500 From: "PFAUTZ, PENN L" To: "rai@ietf.org" Thread-Topic: draft-pfautz-service-provider-identifier-urn-02 Thread-Index: Acztk/liLbWxHFd/QP20bST4OXBw0Q== Date: Fri, 17 Feb 2012 16:48:29 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D608656C@MISOUT7MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.51] Content-Type: multipart/alternative; boundary="_000_38726EDA2109264987B45E29E758C4D608656CMISOUT7MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: [RAI] draft-pfautz-service-provider-identifier-urn-02 X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:48:44 -0000 --_000_38726EDA2109264987B45E29E758C4D608656CMISOUT7MSGUSR9NIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've submitted a new draft of the global SPID document. It differs from th= e previous version in asking the RIRs rather than IANA directly to handle r= egistrations. (This is to minimize junk registrations and provide a whois s= ervice). Comments, please. Penn Pfautz AT&T Access Management +1-732-420-4962 A new version of I-D, draft-pfautz-service-provider-identifier-urn-02.txt h= as been successfully submitted by Penn Pfautz and posted to the IETF reposi= tory. Filename: draft-pfautz-service-provider-identifier-urn Revision: 02 Title: SP URN Creation date: 2012-02-17 WG ID: Individual Submission Number of pages: 5 Abstract: This document requests a service provider identifier URN namespace. --_000_38726EDA2109264987B45E29E758C4D608656CMISOUT7MSGUSR9NIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve submitted a new draft of the global SP= ID document.  It differs from the previous version in asking the RIRs = rather than IANA directly to handle registrations. (This is to minimize jun= k registrations and provide a whois service).

Comments, please.

 

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

 

A new version of I-D, draft-pfautz-service-provid= er-identifier-urn-02.txt has been successfully submitted by Penn Pfautz and= posted to the IETF repository.

 

Filename:   draft-pfautz-service-provid= er-identifier-urn

Revision:   02

Title:       &= nbsp;    SP URN

Creation date:    2012-02-17<= /o:p>

WG ID:       &= nbsp;    Individual Submission

Number of pages: 5

 

Abstract:

   This document requests a service pro= vider identifier URN namespace.

 

 

 

--_000_38726EDA2109264987B45E29E758C4D608656CMISOUT7MSGUSR9NIT_-- From saul@ag-projects.com Mon Feb 20 01:07:52 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606E221F86FE; Mon, 20 Feb 2012 01:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9nj2pDAPB0J; Mon, 20 Feb 2012 01:07:52 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id C363B21F86FC; Mon, 20 Feb 2012 01:07:51 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id 2CFF0B01B7; Mon, 20 Feb 2012 10:07:50 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 86BBEB019B; Mon, 20 Feb 2012 10:07:49 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Mon, 20 Feb 2012 10:07:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <042B7D73-556C-41AB-AC54-E59942D7575C@ag-projects.com> References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> <4F3D43C0.2040005@stpeter.im> <088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org, Peter Saint-Andre Subject: Re: [RAI] [Geopriv] [Simple] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 09:07:52 -0000 Hi, On Feb 16, 2012, at 7:26 PM, Hannes Tschofenig wrote: > I am curious: Why you do schema validation? >=20 > When you receive a PIDF document in a SIP message then you will have = to parse it. Since we put any namespace=3D"##other" statements in nearly = all our schema files I am curious what you actually going to learn from = the validation since almost everything validates without error.=20 >=20 Well, I like to do schema validation to al least know that the document = doesn't violate the specified structure. Yes, you may put whatever you = want in ##other, but PIDF does define certain elements, and those will = not fall in the ##other bucket, so those should be validated. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From pete@tech-know-ware.com Mon Feb 20 02:36:31 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1180521F8743 for ; Mon, 20 Feb 2012 02:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.227 X-Spam-Level: * X-Spam-Status: No, score=1.227 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8S1IxVjmFzLB for ; Mon, 20 Feb 2012 02:36:26 -0800 (PST) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id D8B3F21F8740 for ; Mon, 20 Feb 2012 02:36:25 -0800 (PST) Received: (qmail 30025 invoked from network); 20 Feb 2012 10:36:24 +0000 Received: from unknown (HELO codalogic) (95.146.193.111) by codalogic.com with (RC4-MD5 encrypted) SMTP; 20 Feb 2012 10:36:24 +0000 Message-ID: <4FE9598F0B7E440FBC143D124F4437A6@codalogic> From: "Pete Cordell" To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= , "Hannes Tschofenig" References: <20120214215439.F2F5172F1F1@rfc-editor.org><4F3AE1D5.5030505@nostrum.com><4F3D43C0.2040005@stpeter.im><088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> <042B7D73-556C-41AB-AC54-E59942D7575C@ag-projects.com> X-Unsent: 1 Date: Mon, 20 Feb 2012 10:36:03 -0000 X-Vipre-Scanned: 003FDC34002D30003FDD81 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org, Peter Saint-Andre Subject: Re: [RAI] [Geopriv] [Simple] PLEASE TAKE NOTE: Fwd: [TechnicalErrata Reported] RFC4480 (3121) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 10:36:31 -0000 Original Message From: "Saúl Ibarra Corretgé" > On Feb 16, 2012, at 7:26 PM, Hannes Tschofenig wrote: >> >> I am curious: Why you do schema validation? >> >> When you receive a PIDF document in a SIP message then you will have to >> parse it. Since we put any namespace="##other" statements in nearly all >> our schema files I am curious what you actually going to learn from the >> validation since almost everything validates without error. > Well, I like to do schema validation to al least know that the document > doesn't violate the specified structure. Yes, you may put whatever you > want > in ##other, but PIDF does define certain elements, and those will not fall > in the ##other bucket, so those should be validated. I don't know anything about PIDF, but I know a bit about XML Schema and I think there might be some mis-understanding of what does. If you have a schema fragment like: Then the following would _violate_ the schema: The reason is that the element is specifying that the extension must be in an-other namespace, not the namespace specified by the schema. Something like the following would be OK: So as I understand it, I believe this change could break existing implementations that choose to use schema validation. Whether, given the state of current implementation, that is a issue in practice is a matter for the group. HTH, Pete Cordell Codalogic Ltd Interface XML to C++ the easy way using C++ XML data binding to convert XSD schemas to C++ classes. Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com for more info From saul@ag-projects.com Mon Feb 20 02:39:58 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479A321F8748; Mon, 20 Feb 2012 02:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQMwSbYcCMJt; Mon, 20 Feb 2012 02:39:57 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8323421F8715; Mon, 20 Feb 2012 02:39:57 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id ABB3FB01B8; Mon, 20 Feb 2012 11:39:55 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id EA913B019B; Mon, 20 Feb 2012 11:39:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-Priority: 3 In-Reply-To: <4FE9598F0B7E440FBC143D124F4437A6@codalogic> Date: Mon, 20 Feb 2012 11:39:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1434D56D-2E9D-42A9-94C5-71C88D1D94BA@ag-projects.com> References: <20120214215439.F2F5172F1F1@rfc-editor.org><4F3AE1D5.5030505@nostrum.com><4F3D43C0.2040005@stpeter.im><088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> <042B7D73-556C-41AB-AC54-E59942D7575C@ag-projects.com> <4FE9598F0B7E440FBC143D124F4437A6@codalogic> To: Pete Cordell X-Mailer: Apple Mail (2.1084) Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org, Peter Saint-Andre Subject: Re: [RAI] [Geopriv] [Simple] PLEASE TAKE NOTE: Fwd: [TechnicalErrata Reported] RFC4480 (3121) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 10:39:58 -0000 Hi Pete, >=20 > I don't know anything about PIDF, but I know a bit about XML Schema = and I > think there might be some mis-understanding of what namespace=3D"##other"> does. >=20 > If you have a schema fragment like: >=20 > > > > type=3D"empty" /> > type=3D"empty" /> > type=3D"empty" /> > maxOccurs=3D"unbounded" processContents=3D"lax"/> > > > >=20 > Then the following would _violate_ the schema: >=20 > >=20 > The reason is that the element is specifying that the = extension > must be in an-other namespace, not the namespace specified by the = schema. >=20 > Something like the following would be OK: >=20 > > > >=20 > So as I understand it, I believe this change could > break existing implementations that choose to use schema > validation. Whether, given the state of current implementation, that = is a issue in practice is a matter for the group. >=20 You are right, this was what was pointed out, that the change would make = validating the current schema erroneous. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ben@nostrum.com Mon Feb 20 06:56:34 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335A321F865B; Mon, 20 Feb 2012 06:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLhgOBwhj8Rb; Mon, 20 Feb 2012 06:56:29 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AE58321F8620; Mon, 20 Feb 2012 06:56:29 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q1KEuP4O087385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Feb 2012 08:56:26 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell X-Priority: 3 In-Reply-To: <1434D56D-2E9D-42A9-94C5-71C88D1D94BA@ag-projects.com> Date: Mon, 20 Feb 2012 08:56:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <344A0735-EFF9-4606-AE10-BED9B2CAD3F8@nostrum.com> References: <20120214215439.F2F5172F1F1@rfc-editor.org><4F3AE1D5.5030505@nostrum.com><4F3D43C0.2040005@stpeter.im><088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> <042B7D73-556C-41AB-AC54-E59942D7575C@ag-projects.com> <4FE9598F0B7E440FBC143D124F4437A6@codalogic> <1434D56D-2E9D-42A9-94C5-71C88D1D94BA@ag-projects.com> To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org Subject: Re: [RAI] [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [TechnicalErrata Reported] RFC4480 (3121) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:56:34 -0000 Taking this back to the original question: It looks like we have a rough consensus that the proposed change is not = backward's compatible for devices that validate schemas. Does anyone = disagree at this point?=20 What does that mean for the question of fixing the schema via an = erratum? On Feb 20, 2012, at 4:39 AM, Sa=FAl Ibarra Corretg=E9 wrote: > Hi Pete, >=20 >>=20 >> I don't know anything about PIDF, but I know a bit about XML Schema = and I >> think there might be some mis-understanding of what > namespace=3D"##other"> does. >>=20 >> If you have a schema fragment like: >>=20 >> >> >> >> > type=3D"empty" /> >> > type=3D"empty" /> >> > type=3D"empty" /> >> > maxOccurs=3D"unbounded" processContents=3D"lax"/> >> >> >> >>=20 >> Then the following would _violate_ the schema: >>=20 >> >>=20 >> The reason is that the element is specifying that the = extension >> must be in an-other namespace, not the namespace specified by the = schema. >>=20 >> Something like the following would be OK: >>=20 >> >> >> >>=20 >> So as I understand it, I believe this change could >> break existing implementations that choose to use schema >> validation. Whether, given the state of current implementation, that = is a issue in practice is a matter for the group. >>=20 >=20 > You are right, this was what was pointed out, that the change would = make validating the current schema erroneous. >=20 >=20 > Regards, >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From martin.thomson@gmail.com Mon Feb 20 10:41:10 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5CA21F8600; Mon, 20 Feb 2012 10:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.892 X-Spam-Level: X-Spam-Status: No, score=-3.892 tagged_above=-999 required=5 tests=[AWL=-2.152, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkMQHHcQ3QGg; Mon, 20 Feb 2012 10:41:07 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2E821F85D7; Mon, 20 Feb 2012 10:41:06 -0800 (PST) Received: by bkuw12 with SMTP id w12so5504287bku.31 for ; Mon, 20 Feb 2012 10:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gg0fGXOFV0QhSFech0/dXEqIvL7NZkM7ooau22KEJT4=; b=B7wLkgPzzXTqJeXC/D8aJBXc8qD4O7nJDfD69gRr3WT4tmsx3/cQtuZpY+VslhKYvZ Gj41wS+B3+bfWZa2udqPNH/VX9fsUD1jm9h/VZAXBAT+WhVUMyyDQbC/k6qYjNkz6mwQ YVAphgCD+q1fFtljiOBmdf7m9/J1Byr02U75c= MIME-Version: 1.0 Received: by 10.204.132.84 with SMTP id a20mr4400111bkt.21.1329763265620; Mon, 20 Feb 2012 10:41:05 -0800 (PST) Received: by 10.204.241.81 with HTTP; Mon, 20 Feb 2012 10:41:05 -0800 (PST) In-Reply-To: <344A0735-EFF9-4606-AE10-BED9B2CAD3F8@nostrum.com> References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> <4F3D43C0.2040005@stpeter.im> <088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> <042B7D73-556C-41AB-AC54-E59942D7575C@ag-projects.com> <4FE9598F0B7E440FBC143D124F4437A6@codalogic> <1434D56D-2E9D-42A9-94C5-71C88D1D94BA@ag-projects.com> <344A0735-EFF9-4606-AE10-BED9B2CAD3F8@nostrum.com> Date: Mon, 20 Feb 2012 10:41:05 -0800 Message-ID: From: Martin Thomson To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org Subject: Re: [RAI] [Geopriv] [Simple] PLEASE TAKE NOTE: Fwd: [TechnicalErrata Reported] RFC4480 (3121) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:41:10 -0000 On 20 February 2012 06:56, Ben Campbell wrote: > What does that mean for the question of fixing the schema via an erratum? Add a note to the erratum: The "lunch" element cannot be used without risk of the document being rejected. --Martin p.s. Non-existence of a midday meal is consistent with some workplace policies. However, in some jurisdictions such a policy may be considered illegal according to workplace legislation. From pkyzivat@alum.mit.edu Mon Feb 20 19:28:43 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900E721E803B for ; Mon, 20 Feb 2012 19:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB24s--rjkgG for ; Mon, 20 Feb 2012 19:28:42 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id DA68621E8016 for ; Mon, 20 Feb 2012 19:28:41 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta01.westchester.pa.mail.comcast.net with comcast id cTCo1i0051wpRvQ51TUiW9; Tue, 21 Feb 2012 03:28:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id cTUh1i00y07duvL3eTUhWH; Tue, 21 Feb 2012 03:28:42 +0000 Message-ID: <4F430F68.5090307@alum.mit.edu> Date: Mon, 20 Feb 2012 22:28:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rai@ietf.org References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> <4F3D43C0.2040005@stpeter.im> <088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> <042B7D73-556C-41AB-AC54-E59942D7575C@ag-projects.com> <4FE9598F0B7E440FBC143D124F4437A6@codalogic> <1434D56D-2E9D-42A9-94C5-71C88D1D94BA@ag-projects.com> <344A0735-EFF9-4606-AE10-BED9B2CAD3F8@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [RAI] [Geopriv] [Simple] PLEASE TAKE NOTE: Fwd: [TechnicalErrata Reported] RFC4480 (3121) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 03:28:43 -0000 On 2/20/12 1:41 PM, Martin Thomson wrote: > On 20 February 2012 06:56, Ben Campbell wrote: >> What does that mean for the question of fixing the schema via an erratum? > > Add a note to the erratum: The "lunch" element cannot be used without > risk of the document being rejected. "lunch" could be defined in a new namespace. Ugly, but its consistent with the intended extension mechanisms. Thanks, Paul From pkyzivat@alum.mit.edu Tue Feb 21 17:51:14 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3D021E8023 for ; Tue, 21 Feb 2012 17:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bslA+Wxk4hbW for ; Tue, 21 Feb 2012 17:51:13 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5563821E801E for ; Tue, 21 Feb 2012 17:51:13 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta06.westchester.pa.mail.comcast.net with comcast id cpHW1i00227AodY56prD4D; Wed, 22 Feb 2012 01:51:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id cprD1i00907duvL3fprDHh; Wed, 22 Feb 2012 01:51:13 +0000 Message-ID: <4F444A0B.2090908@alum.mit.edu> Date: Tue, 21 Feb 2012 20:51:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "rai@ietf.org" References: <20120221213428.9641.76358.idtracker@ietfa.amsl.com> In-Reply-To: <20120221213428.9641.76358.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [RAI] I-D Action: draft-ietf-sipping-media-policy-dataset-14.txt X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 01:51:14 -0000 (I guess this must go to RAI, since sipping is now closed) Somehow I managed to ignore this up till now. I have déjà vu reading this - it feels like SDPng has returned. :-) I see one possible problem with this: > 4.1. Mapping SDP to Session Info Documents > > If a UA has an SDP offer and answer pair [RFC3264] and wants to > create a session info document, the UA uses the answer to fill in the > elements of the session info document except for the port> and elements, which are taken from the remote > and local SDP respectively. (The local SDP is the one sent by the > UA; the remote session description is the one received from the > remote UA.) I think this isn't quite right. Specifically, the m-line in the offer can contain those formats from the offer that the answerer wants to use. But it may also contain additional formats that the answerer supports. But those added ones, and the formats in the offer that are not in the answer, cannot be used for the session at that time. I think your mapping procedure improperly includes the formats from the answer that weren't in the offer. I guess the mapping could simply say to omit those. Or you could include elements for those mentioned in offer or answer but not both with enabled=no and perhaps direction to indicate which side named it. Thanks, Paul From gonzalo.camarillo@ericsson.com Tue Feb 28 03:20:04 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB83F21F858F for ; Tue, 28 Feb 2012 03:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.241 X-Spam-Level: X-Spam-Status: No, score=-110.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ606DGyM0Ex for ; Tue, 28 Feb 2012 03:20:04 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B768A21F8589 for ; Tue, 28 Feb 2012 03:20:03 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-5b-4f4cb862137b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DD.4E.01970.268BC4F4; Tue, 28 Feb 2012 12:20:02 +0100 (CET) Received: from [131.160.36.141] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Tue, 28 Feb 2012 12:20:02 +0100 Message-ID: <4F4CB861.4090805@ericsson.com> Date: Tue, 28 Feb 2012 13:20:01 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rai@ietf.org X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [RAI] How to exchange metadata about the media streams established with a SIP session X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 11:20:05 -0000 Folks, I am sending this email to the RAI list because it is about an architectural issue that affects more than one WG. Both the CLUE and SIPREC WGs have identified the need to exchange metadata about media streams that have been established using SIP. Both groups need to transport such metadata between SIP UAs. In CLUE, they are studying how to transport their metadata, as documented in: http://tools.ietf.org/html/draft-wenger-clue-transport-01 In SIPREC, they are planning to piggyback the metadata in SIP UPDATEs as an XML-encoded body part. When they need to send a request for full state (as opposed to partial state), they use an UPDATE request with a particular body type, as documented in: http://tools.ietf.org/html/draft-ietf-siprec-protocol-02 The best way to exchange metadata within a SIP session depends on the type of metadata and on how the UAs need to interact with each other (e.g., a UA simply pushing information to the other UA or a more complicated protocol). Given that SIPREC and CLUE have different metadata and interactions, it may well be that we decide to use a different mechanism in each group. Nevertheless, I think both groups would benefit from architecturally-inclined RAI people having a look at their work. Please, continue this discussion focusing on their specific requirements on either the CLUE list or the SIPREC list. Somewhat related to this issue, the RTCWeb group discussed the use of SCTP over UDP as a reliable NAT-friendly way to exchange data between endpoints. Cheers, Gonzalo From pravindran@sonusnet.com Tue Feb 28 03:49:18 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A89221F8619 for ; Tue, 28 Feb 2012 03:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD+aoJu50NAK for ; Tue, 28 Feb 2012 03:49:17 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 282A921F8613 for ; Tue, 28 Feb 2012 03:49:17 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1SBo2iH022578; Tue, 28 Feb 2012 06:50:02 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 06:49:13 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 17:19:10 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 28 Feb 2012 17:19:09 +0530 From: "Ravindran, Parthasarathi" To: Gonzalo Camarillo , "rai@ietf.org" Thread-Topic: [RAI] How to exchange metadata about the media streams established with a SIP session Thread-Index: AQHM9grzSsDTVY7e0UuDtFmiVKlxPZZSLCVw Date: Tue, 28 Feb 2012 11:49:10 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E05106E@inba-mail01.sonusnet.com> References: <4F4CB861.4090805@ericsson.com> In-Reply-To: <4F4CB861.4090805@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2012 11:49:10.0427 (UTC) FILETIME=[FBF8E6B0:01CCF60E] Subject: Re: [RAI] How to exchange metadata about the media streams established with a SIP session X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 11:49:18 -0000 Hi all, Just adding more information about SIPREC protocol, "SIPREC Metadata is tra= nsported in the body of INVITE or UPDATE or RE-INVITE or any SIP message wi= th SDP from Session recording client (SRC) to Session Recording Server(SRS)= . Metadata request from SRS is a separate UPDATE transaction and SRC replie= s metadata in the subsequent transaction using RE-INVITE or UPDATE." Thanks Partha >-----Original Message----- >From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of >Gonzalo Camarillo >Sent: Tuesday, February 28, 2012 4:50 PM >To: rai@ietf.org >Subject: [RAI] How to exchange metadata about the media streams >established with a SIP session > >Folks, > >I am sending this email to the RAI list because it is about an >architectural issue that affects more than one WG. > >Both the CLUE and SIPREC WGs have identified the need to exchange >metadata about media streams that have been established using SIP. Both >groups need to transport such metadata between SIP UAs. > >In CLUE, they are studying how to transport their metadata, as >documented in: >http://tools.ietf.org/html/draft-wenger-clue-transport-01 > >In SIPREC, they are planning to piggyback the metadata in SIP UPDATEs as >an XML-encoded body part. When they need to send a request for full >state (as opposed to partial state), they use an UPDATE request with a >particular body type, as documented in: >http://tools.ietf.org/html/draft-ietf-siprec-protocol-02 > >The best way to exchange metadata within a SIP session depends on the >type of metadata and on how the UAs need to interact with each other >(e.g., a UA simply pushing information to the other UA or a more >complicated protocol). Given that SIPREC and CLUE have different >metadata and interactions, it may well be that we decide to use a >different mechanism in each group. Nevertheless, I think both groups >would benefit from architecturally-inclined RAI people having a look at >their work. Please, continue this discussion focusing on their specific >requirements on either the CLUE list or the SIPREC list. > >Somewhat related to this issue, the RTCWeb group discussed the use of >SCTP over UDP as a reliable NAT-friendly way to exchange data between >endpoints. > >Cheers, > >Gonzalo > >_______________________________________________ >RAI mailing list >RAI@ietf.org >https://www.ietf.org/mailman/listinfo/rai From mary.ietf.barnes@gmail.com Tue Feb 28 07:36:23 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6FC21F86A4 for ; Tue, 28 Feb 2012 07:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.622 X-Spam-Level: X-Spam-Status: No, score=-103.622 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTAdTvjWuItD for ; Tue, 28 Feb 2012 07:36:20 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96DD721F85E1 for ; Tue, 28 Feb 2012 07:36:18 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1860060vcb.31 for ; Tue, 28 Feb 2012 07:36:17 -0800 (PST) Received-SPF: pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.70.165 as permitted sender) client-ip=10.52.70.165; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.70.165 as permitted sender) smtp.mail=mary.ietf.barnes@gmail.com; dkim=pass header.i=mary.ietf.barnes@gmail.com Received: from mr.google.com ([10.52.70.165]) by 10.52.70.165 with SMTP id n5mr13606267vdu.55.1330443377304 (num_hops = 1); Tue, 28 Feb 2012 07:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hi7b6Pu78fdA+IBQwUKYwNEMIKakFQ3pE7XGJhCKJzE=; b=LYEwWgJvH/Xt5xcqPhhKJIFm+GAKozLuYdMttwZjs6uSfDb3W6z3F2UQIh4IZ2jUIv P45lO70di8I1Jdkp/TMIMSUTp+O8CgEUG/gSQDGg8TwMERMWQCocBAHy75Yn0tsBBWZw S2s/J32qXDF8e8mlEgQaVF6XYd014CyTK/smg= MIME-Version: 1.0 Received: by 10.52.70.165 with SMTP id n5mr11208524vdu.55.1330443377252; Tue, 28 Feb 2012 07:36:17 -0800 (PST) Received: by 10.52.34.138 with HTTP; Tue, 28 Feb 2012 07:36:17 -0800 (PST) In-Reply-To: <4F4CB861.4090805@ericsson.com> References: <4F4CB861.4090805@ericsson.com> Date: Tue, 28 Feb 2012 09:36:17 -0600 Message-ID: From: Mary Barnes To: Gonzalo Camarillo Content-Type: multipart/alternative; boundary=bcaec5015e53e5193104ba07fc18 Cc: rai@ietf.org Subject: Re: [RAI] How to exchange metadata about the media streams established with a SIP session X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 15:36:23 -0000 --bcaec5015e53e5193104ba07fc18 Content-Type: text/plain; charset=ISO-8859-1 There is additional detail (and drafts) on the signaling options for CLUE being discussed in these email threads: http://www.ietf.org/mail-archive/web/clue/current/msg01076.html http://www.ietf.org/mail-archive/web/clue/current/msg01089.html So, if anyone chooses to contribute to the discussion in CLUE, this email discussion is a good place to start. I also think the problem spaces are different enough that having a common mechanism should not be required (or expected). Mary. CLUE WG co-chair On Tue, Feb 28, 2012 at 5:20 AM, Gonzalo Camarillo < Gonzalo.Camarillo@ericsson.com> wrote: > Folks, > > I am sending this email to the RAI list because it is about an > architectural issue that affects more than one WG. > > Both the CLUE and SIPREC WGs have identified the need to exchange > metadata about media streams that have been established using SIP. Both > groups need to transport such metadata between SIP UAs. > > In CLUE, they are studying how to transport their metadata, as > documented in: > http://tools.ietf.org/html/draft-wenger-clue-transport-01 > > In SIPREC, they are planning to piggyback the metadata in SIP UPDATEs as > an XML-encoded body part. When they need to send a request for full > state (as opposed to partial state), they use an UPDATE request with a > particular body type, as documented in: > http://tools.ietf.org/html/draft-ietf-siprec-protocol-02 > > The best way to exchange metadata within a SIP session depends on the > type of metadata and on how the UAs need to interact with each other > (e.g., a UA simply pushing information to the other UA or a more > complicated protocol). Given that SIPREC and CLUE have different > metadata and interactions, it may well be that we decide to use a > different mechanism in each group. Nevertheless, I think both groups > would benefit from architecturally-inclined RAI people having a look at > their work. Please, continue this discussion focusing on their specific > requirements on either the CLUE list or the SIPREC list. > > Somewhat related to this issue, the RTCWeb group discussed the use of > SCTP over UDP as a reliable NAT-friendly way to exchange data between > endpoints. > > Cheers, > > Gonzalo > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai > --bcaec5015e53e5193104ba07fc18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is additional detail (and drafts) on the signaling options for CLUE b= eing discussed in these email threads:
http://www.ietf.org/mail-archive/web/clue/current/msg01089.html
So, if anyone chooses to contribute to the discussion in CLUE, thi= s email discussion is a good place to start.

I also think the problem spaces are different enough th= at having a common mechanism should not be required (or expected). =A0

Mary.=A0
CLUE WG co-chair

On Tue, Feb 28, 2012 at 5:20 AM, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.= com> wrote:
Folks,

I am sending this email to the RAI list because it is about an
architectural issue that affects more than one WG.

Both the CLUE and SIPREC WGs have identified the need to exchange
metadata about media streams that have been established using SIP. Both
groups need to transport such metadata between SIP UAs.

In CLUE, they are studying how to transport their metadata, as
documented in:
http://tools.ietf.org/html/draft-wenger-clue-transport-01<= br>
In SIPREC, they are planning to piggyback the metadata in SIP UPDATEs as an XML-encoded body part. When they need to send a request for full
state (as opposed to partial state), they use an UPDATE request with a
particular body type, as documented in:
http://tools.ietf.org/html/draft-ietf-siprec-protocol-02
The best way to exchange metadata within a SIP session depends on the
type of metadata and on how the UAs need to interact with each other
(e.g., a UA simply pushing information to the other UA or a more
complicated protocol). Given that SIPREC and CLUE have different
metadata and interactions, it may well be that we decide to use a
different mechanism in each group. Nevertheless, I think both groups
would benefit from architecturally-inclined RAI people having a look at
their work. Please, continue this discussion focusing on their specific
requirements on either the CLUE list or the SIPREC list.

Somewhat related to this issue, the RTCWeb group discussed the use of
SCTP over UDP as a reliable NAT-friendly way to exchange data between
endpoints.

Cheers,

Gonzalo

_______________________________________________
RAI mailing list
RAI@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/rai

--bcaec5015e53e5193104ba07fc18--