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
>