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

["DRAGE, Keith (Keith)" <[e-mail]>]

Remember that the IANA considerations needs to deal with all existing usages and that now includes bliss-call-completions.

If you create a new registry, you need to define the policy for adding to that registry.

This is the "purpose" header field parameter, rather than just "purpose" parameter. Amend throughout.

Keith

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Shekh-Yusef, Rifaat (Rifaat)
> Sent: 04 March 2013 21:51
> To: Paul Kyzivat; [e-mail]
> Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
> 
> 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: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Paul Kyzivat
> > Sent: Monday, March 04, 2013 4:27 PM
> > To: [e-mail]
> > 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: [e-mail] [mailto:[e-mail]]
> > On
> > >> Behalf Of Peter Saint-Andre
> > >> Sent: Monday, March 04, 2013 2:04 PM
> > >> To: Olle E. Johansson
> > >> Cc: Cullen Jennings (fluffy); [e-mail]; 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)"
> > >>> <[e-mail]>:
> > >>>
> > >>>>
> > >>>> 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:[e-mail]> ;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
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/dispatch
> > > _______________________________________________
> > > dispatch mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dispatch
> > >
> >
> > _______________________________________________
> > dispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch