Re: [dispatch] URI schemes in P-Asserted-Identity

"Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com> Mon, 04 March 2013 21:51 UTC

Return-Path: <rifatyu@avaya.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1D021F8C54 for <dispatch@ietfa.amsl.com>; Mon, 4 Mar 2013 13:51:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.349
X-Spam-Level:
X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-0.750, 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 6JTVVfXBecuF for <dispatch@ietfa.amsl.com>; Mon, 4 Mar 2013 13:51:17 -0800 (PST)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id E05B821F83E1 for <dispatch@ietf.org>; Mon, 4 Mar 2013 13:51:16 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFALh+MVGHCzI1/2dsb2JhbAA7CQ6CWL9egQAWc4IfAQEBAQMBAQEPKDQXBAIBCA0BAwQBAQEKFAkHJwsUCQgCBAESCAEZh3EBC6QcnEONU4EZJhIGgllhA5xcilKCST+CJw
X-IronPort-AV: E=Sophos;i="4.84,766,1355115600"; d="scan'208";a="260630"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Mar 2013 16:51:16 -0500
Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 04 Mar 2013 16:49:54 -0500
Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.02.0328.009; Mon, 4 Mar 2013 16:51:15 -0500
From: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: [dispatch] URI schemes in P-Asserted-Identity
Thread-Index: AQHOGQr9SIPFU2v3v02dtExy7g61EJiV51LAgAB4VAD//7HV4A==
Date: Mon, 04 Mar 2013 21:51:15 +0000
Message-ID: <C563F76EA324474CA3722A35154AFDB3139DF3C7@AZ-US1EXMB01.global.avaya.com>
References: <51102D21.10503@stpeter.im> <C5E08FE080ACFD4DAE31E4BDBF944EB11340A073@xmb-aln-x02.cisco.com> <CAPvvaaJn4j0+bqK-de8ecou8fRRfDiXyF4d7piDDgyp8BWZsDg@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB11340B040@xmb-aln-x02.cisco.com> <F2998B6B-0D1E-4DFD-8193-450B138DF57E@edvina.net> <5134F00F.9030301@stpeter.im> <C563F76EA324474CA3722A35154AFDB3139DF21B@AZ-US1EXMB01.global.avaya.com> <51351190.5040408@alum.mit.edu>
In-Reply-To: <51351190.5040408@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.11.85.47]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2013 21:51:18 -0000

Ok. I will clean up the draft and submit it to the SIPCORE when the submission tool reopens next week.

Regards,
 Rifaat


> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: Monday, March 04, 2013 4:27 PM
> To: dispatch@ietf.org
> Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
> 
> On 3/5/13 3:25 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> > Peter,
> >
> > Today, there is no registry for the "purpose" values in the Call-Info
> header.
> > Mary and I have an open issue around this in the following draft, as
> we would like to register a "ccmp" value.
> > https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp-
> indication/?include_text=1
> 
> Recently sipcore seems to have gotten into the business of establishing
> missing registries for 3261. We can certainly do another one.
> 
> 	Thanks,
> 	Paul
> 
> > Please, keep us posted on your discussion with IANA on this.
> >
> > Regards,
> >   Rifaat
> >
> >
> >> -----Original Message-----
> >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org]
> On
> >> Behalf Of Peter Saint-Andre
> >> Sent: Monday, March 04, 2013 2:04 PM
> >> To: Olle E. Johansson
> >> Cc: Cullen Jennings (fluffy); dispatch@ietf.org; Emil Ivov
> >> Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 3/4/13 1:51 AM, Olle E. Johansson wrote:
> >>>
> >>> 3 mar 2013 kl. 14:12 skrev "Cullen Jennings (fluffy)"
> >>> <fluffy@cisco.com>:
> >>>
> >>>>
> >>>> If you don't want to do the vcard but just want the xmpp address
> >>>> directly, I'd probably suggest something like
> >>>>
> >>>> Call-Info: <xmpp:aice@example.com> ;purpose=impp
> >>>>
> >>>> To just indicate that the URL provided the IM and Presence
> >>>> service for that user
> >>>>
> >>>> RFC 3261 section 20.9 says that the IANA section of 3261 will
> >>>> define how to add a new purpose but as far as I can tell it does
> >>>> not. However, the IANA SIP registry for the URI purpose at
> >>>>
> >>>> http://www.iana.org/assignments/sip-parameters/sip-
> >> parameters.xml#sip-parameters-13
> >>>>
> >>>>
> >>>>
> >> is just spec required so I think think you might be able to trivial
> add
> >> a "impp" purpose.
> >>> Shouldn't the purposes in RFC 3261 be added to that registry too?
> >>
> >> Hej Olle,
> >>
> >> Yeah, I went searching for those in the registry yesterday and
> >> couldn't find them. It sounds like someone needs to register them.
> >>
> >> RFC 3261 says:
> >>
> >>     The Call-Info header field provides additional information about
> the
> >>     caller or callee, depending on whether it is found in a request
> or
> >>     response.  The purpose of the URI is described by the "purpose"
> >>     parameter.  The "icon" parameter designates an image suitable as
> an
> >>     iconic representation of the caller or callee.  The "info"
> parameter
> >>     describes the caller or callee in general, for example, through
> a
> >> web
> >>     page.  The "card" parameter provides a business card, for
> example,
> >> in
> >>     vCard [36] or LDIF [37] formats.  Additional tokens can be
> >> registered
> >>     using IANA and the procedures in Section 27.
> >>
> >> Actually, I think "icon", "info", and "card" are values of the
> >> "purpose" parameter, not parameters in themselves, right?
> >>
> >> I find the Header Field Parameters and Parameter Values registry a
> bit
> >> confusing:
> >>
> >> https://www.iana.org/assignments/sip-parameters/sip-
> parameters.xml#sip-
> >> parameters-12
> >>
> >> Some of those header fields have predefined values. It's not clear
> to
> >> me if those values need to be registered. Section 20.9 of RFC 3261
> >> says they do, but Section 27 doesn't say how. (When oh when is
> someone
> >> going to work on 3261bis? ;-)
> >>
> >> Olle/Emil, how about you and I take this up with IANA folks during
> >> their office hours in Orlando?
> >>
> >> Peter
> >>
> >> - --
> >> Peter Saint-Andre
> >> https://stpeter.im/
> >>
> >>
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >>
> >> iQIcBAEBAgAGBQJRNPAPAAoJEOoGpJErxa2pgvwP/jnZrFSx3H82349715qd6jN2
> >> /rWF+VLF73tEBHX/ssBaBr4Kwu/RJ+oYK6+jNYbpiq9cmUEsSLjOJOY0frygUHej
> >> rE/uV5CtXwkn453yWX2ocEUHXI5bnrgENXxqPy2YITXETogf+Ybbs00IrvneMzdL
> >> FVnxYXFYVWKmKIPbgrGxVD4xDH030yQyxzewUDm6TrF/R3LoSlwULYxle4jfgyYm
> >> 3bVh64DBsQto39MvtY32abHP1WF1Iav76o7GT0aBb3A09Xv+NkmyRk3EpSbUpj0K
> >> 0zksaLV3bXivBKKjjC3tV9QiDPCD5bYfqQh5UyiJ+PVYOxGFOt191AfH+8oqyowV
> >> cpMXDWPeewRoUaskuTyXsPgL5TiCoeBzOgDF+SnLHk5Uq78tjyrH5YJOHD2Zd1AS
> >> LKn0Xqnb2yZdeFqCEoBAZfAo5W64dj5FF+03+98NxJ4IKFHBob6x/NpeSc3EAvit
> >> iJxzki6l+MpdK2yd6SbvaMPf2UlqOXBpPuDmxM1SlmgJbWFV3BpvoOjGGHGQcz+v
> >> 3W13GAv4HXp3LtpgCduAUtBmDsMxydPwy+Zsm2bhkr0XChK9VX2HqbktaU2qOHU5
> >> QOLqLh5RWFcdK4WVkEtqoNvwHVFq53zC25Ujnq/niBUBm7lvHpuO0E029Gu0AtMY
> >> WnUZHMGNtbAV+KlfHip2
> >> =7auh
> >> -----END PGP SIGNATURE-----
> >> _______________________________________________
> >> dispatch mailing list
> >> dispatch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dispatch
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch