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

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 2 Mar 2013 23:33:31 +0000

I'd be fascinated to hear the need for this - PAI is such a disaster zone that I'd want to make sure the envisioned usage did not run into the many land mines around PAI. It might be that some other header might meet the needs better than PAI. 

Cullen - co-authors of the ill fated RFC 3325 

PS - you might want consider the "Call-Info" header - it would be very cool to the have HTTP URL in that pointed at the JSON vCard for the user. 

See http://tools.ietf.org/html/rfc3261#section-20.9

On Feb 4, 2013, at 3:50 PM, Peter Saint-Andre <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dear DISPATCHers,
> 
> At the XMPP Summit last week, for various reasons that aren't
> particularly relevant here, we talked a bit about how to include an
> XMPP address in the header of a SIP message. Folks at the meeting
> concluded that the P-Asserted-Identity header would work quite well
> (certainly better than a second Contact header). Unfortunately, RFC
> 3225 defines the P-Asserted-Identity as follows:
> 
>   A P-Asserted-Identity header field value MUST consist of exactly one
>   name-addr or addr-spec.  There may be one or two P-Asserted-Identity
>   values.  If there is one value, it MUST be a sip, sips, or tel URI.
>   If there are two values, one value MUST be a sip or sips URI and the
>   other MUST be a tel URI.
> 
> It's not clear to me why the definition restricts the scheme to sip,
> sips, or tel. Could someone provide some insight about that? Would
> things break if we allowed more URI schemes there, in particular the
> xmpp scheme?
> 
> Thanks!
> 
> 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/
> 
> iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg
> 6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/
> =lu3v
> -----END PGP SIGNATURE-----
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 02 Mar 2013 19:36:27 -0700

On 3/2/13 4:33 PM, Cullen Jennings (fluffy) wrote:
> 
> I'd be fascinated to hear the need for this - PAI is such a
> disaster zone that I'd want to make sure the envisioned usage did
> not run into the many land mines around PAI. It might be that some
> other header might meet the needs better than PAI.

We don't *need* PAI, but we'd like some way to indicate over SIP the
XMPP address of a dual-stack user agent.

> PS - you might want consider the "Call-Info" header - it would be 
> very cool to the have HTTP URL in that pointed at the JSON vCard
> for the user.
> 

That looks like just the ticket, thanks!

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Emil Ivov <[email-masked]>
Date: Sun, 3 Mar 2013 14:31:51 +0200

Hey Cullen,

On Sun, Mar 3, 2013 at 1:33 AM, Cullen Jennings (fluffy)
<[email-masked]> wrote:
>
>
> I'd be fascinated to hear the need for this

As Peter already mentioned: we need to be able to match an incoming
INVITE to a JID so we are looking for the most convenient way to do
this without defining a new header. Partially because we'd like to
keep all this as an informational effort and in part because, as you
said it your self in Vancouver: there has to be an existing header
that we could use for this.

> - PAI is such a disaster zone that I'd want to make sure the envisioned
> usage did not run into the many land mines around PAI. It might be that
> some other header might meet the needs better than PAI.

Well right now we basically say that if you are operating in a trusted
domain, then you use PAI, if not you can still use
P-Preferred-Identity as an indication but then you still have to
validate that the JID from PPI has a vCard that matches the caller. In
other words, you still have to get the vCard but at least you can do
so for a single contact and not your entire roster.

> PS - you might want consider the "Call-Info" header -

OK, this does look like it could also do the job and we even have the
"card" info-param. Thanks for the tip!

> it would be very cool to the have HTTP URL in that pointed at the
> JSON vCard for the user.

Does it have to be HTTP? Would it make sense to use it with an xmpp:
URI? The grammar seems to allow for a generic URI and I don't think
there would be much ambiguity in a header that looks like this:

Call-Info: <xmpp:[email-masked]> ;purpose=card

It seems like this could only mean that Alice's vCard can be retrieved
through XMPP and it would probably be safe to infer that the XMPP URI
mentioned there is her own JID (and "safe to infer" is really what
this draft is all about). WDYT?

I am also wondering if we should repeat the URI with purpose=icon in
order to get the XMPP avatar or if having "card" one would suffice.

Finally, we'd still need to keep the requirement for a cross check:
whatever Call-Info says, one needs to download that vCard and make
sure that a number in there matches the source of the current call.
Otherwise this can be an attack.

Cheers,
Emil

--
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
http://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sun, 3 Mar 2013 13:12:27 +0000

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:[email-masked]> ;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. 

As a side note, I'm very much in favor of the SIP messages being able to provide the XMPP address related to the user so glad to see this work getting done.

Cullen

PS -  Seriously,  PAI is not the header your are looking for.

---

From: Emil Ivov <[email-masked]>
Date: Sun, 03 Mar 2013 18:08:28 +0200

On 03.03.13, 15:12, Cullen Jennings (fluffy) wrote:
> 
> If you don't want to do the vcard 

On the contrary, vCard seems quite reasonable to me. I am also
comfortable with using the xmpp: address in such a vCard as a general
IMPP address. Do you see a problem with it?

> but just want the xmpp address directly, I'd probably suggest something like 
> 

Even if it is trivial, can we actually do that from an informational
document?

> As a side note, I'm very much in favor of the SIP messages being able to provide the XMPP address related to the user so glad to see this work getting done.

Great! Thanks for your support.

> PS -  Seriously,  PAI is not the header your are looking for. 

OK sure. We weren't particularly stuck on it anyway. It did seem to be
somewhat overloaded and if we can just do a "card" XMPP URI in a
Call-Info then this really seems like the easiest way forward.

Cheers,
Emil

-- 
https://jitsi.org

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 4 Mar 2013 09:51:28 +0100

> 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?

/O

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 4 Mar 2013 11:38:42 -0500 (EST)

> From: "Cullen Jennings (fluffy)" <[email-masked]>
> 
> very cool to the have HTTP URL in that pointed at the JSON vCard for
> the user. 
> 

Ah, yes, that's a good place to carry additional URLs.  It's already
been used to support call-completion.

Dale

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Mar 2013 12:03:43 -0700

On 3/4/13 1:51 AM, Olle E. Johansson wrote:
>> If you don't want to do the vcard but just want the xmpp address
>> directly, I'd probably suggest something like
>> 
>> 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
>> 
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/

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Mon, 4 Mar 2013 19:25:16 +0000

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

Please, keep us posted on your discussion with IANA on this.

Regards,
 Rifaat

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Saint-Andre
> Sent: Monday, March 04, 2013 2:04 PM
> To: Olle E. Johansson
> Cc: Cullen Jennings (fluffy); [email-masked]; Emil Ivov
> Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
> 
> 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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 4 Mar 2013 20:55:56 +0100

> their office hours in Orlando?

Sorry,
Don't have the resources to go there. WIll be available online most of the time though.

/O

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Mar 2013 13:20:17 -0700

On 3/4/13 12:25 PM, 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. 

Thinking about this further, I realize we might need a new, very short
I-D that creates the registry. I think this is something that one of
us could write in an hour. I'd be happy to do that before the I-D
submission window opens again.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Mon, 4 Mar 2013 21:08:10 +0000

Peter,

Take a look at the attached document and let me know if that is good enough as a starting point.

Regards,
 Rifaat

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Monday, March 04, 2013 3:20 PM
> To: Shekh-Yusef, Rifaat (Rifaat)
> Cc: Olle E. Johansson; Cullen Jennings (fluffy); [email-masked];
> Emil Ivov
> iQIcBAEBAgAGBQJRNQIAAAoJEOoGpJErxa2pJDwQAJljt/cq/Lx3L+BRR7O/2BZx
> 2pTJHA2RT5EhX897dkTvvLPvgXFlSrXw8k3r1zNKqfAe+ZLbUoIxyhvoA2swuKOI
> qBB+tGZPZ6JyLHgYOKGUXERCsroIhIpjF3bR/BD4yhiwQdJ+A0kzZAJZjl5eMQM5
> UgR7am+6jfqrJmlq7K8JBB7KxNunPkDBRpySoxj5qn1xFB3Nvafp038WVvzC2ARE
> k4PRyUgELKy7L8cXNohq/PbGk7joGE95UtCJH2KXLfVQJCHclPbmUxnUklTKb0r+
> EJgX94sGzi4Vx59GsM0K/rPmkPBEtZ8EzPQ0T6/TzL0jquunM39IzVVz6zJALRcT
> /lBLWk7XkevvWFdtKE4pel/Fp/hTwZgAcuM2//TGRQyLxLn6Xwje+RenTIt9yGtd
> dNrwW2QTlXmjZ41RWhLvubQXI1DYRLM38VoH6BoaiYk7zMoGpHDeq8077Hhhs907
> 9ROUY2GGO7gwT599TowaWji/7Rw8p3W87nuNVFXy1Zz6CuHay8GksvHdLtXIT5Kc
> tBFnqS8rbWIJ1HQrb92E7GTAfYzhDd/CRj7BbaLUCEU2LGqMzfamXcbuJLtkbzzb
> URrA7b6Y1CVE8vJPeBV+HY0sYru4utf14UHkLNvZiVu5MTzyRE5sGNLNSj2rHVmA
> r2cfHMCniL0TR7NHJ6GS
> =H0iU

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Mar 2013 05:26:40 +0800

> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Mar 2013 14:29:24 -0700

> good enough as a starting point.

Looks good, thanks! Per Paul's note, you probably want to chat with
the sipcore chairs about it.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Mon, 4 Mar 2013 21:51:15 +0000

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

Regards,
 Rifaat

> Behalf Of Paul Kyzivat
> Sent: Monday, March 04, 2013 4:27 PM
> To: [email-masked]
> > Mary and I have an open issue around this in the following draft, as
> we would like to register a "ccmp" value.
> >>     describes the caller or callee in general, for example, through
> a
> >> web
> >>     page.  The "card" parameter provides a business card, for
> example,
> >> in
> >> https://www.iana.org/assignments/sip-parameters/sip-
> parameters.xml#sip-
> >> parameters-12
> >>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 5 Mar 2013 13:10:39 +0100

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

> Behalf Of Shekh-Yusef, Rifaat (Rifaat)
> Sent: 04 March 2013 21:51
> To: Paul Kyzivat; [email-masked]

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 5 Mar 2013 12:37:44 +0000

Thanks Keith,

I will address your comments in the sipcore -00 draft.

Regards,
 Rifaat

Sent from my iPhone

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Mar 2013 09:59:48 -0700

On 3/5/13 5:37 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> Regards, Rifaat
>> Remember that the IANA considerations needs to deal with all
>> existing usages and that now includes bliss-call-completions.
>> 

Rifaat, see RFC 5226 for the policy definitions. In the Applications
Area folks have been trying to make it easier for people to register
things, but that might not be true in RAI. We can discuss on SIPCORE,
I suppose. :-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 5 Mar 2013 13:31:43 -0500 (EST)

> draft-yusef-dispatch-purpose-00.txt

At the least, you need to include the value "call-completion", defined
in draft-ietf-bliss-call-completion, which is now in the RFC Editor
queue.

But it's not clear to me that we need to go to this much effort, as
there are currently only four documents that define values for this
parameter, and their names fit into the space in
http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-12

Dale

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Mar 2013 11:51:13 -0700

On 3/5/13 11:31 AM, Dale R. Worley wrote:
> At the least, you need to include the value "call-completion",
> defined in draft-ietf-bliss-call-completion, which is now in the
> RFC Editor queue.
> 
> But it's not clear to me that we need to go to this much effort,
> as there are currently only four documents that define values for
> this parameter, and their names fit into the space in 

Maybe
you're right.

Section 20.9 of RFC 3261 states:

The existing registrations don't define a registry but instead ask
that the relevant specification be added to the rightmost column.

See for instance RFC 5367:

###

9.1. List-Management Purpose Parameter Value

   This document defines the 'list-management' value for the "purpose"
   parameter of the Call-Info header field.  A reference to this RFC (in
   double brackets) has been added to the existing "purpose" Call-Info
   parameter entry in the SIP Parameters registry, which currently looks
   as follows:

                                                  Predefined
   Header Field                  Parameter Name     Values     Reference
   ----------------------------  ---------------   ---------   ---------
   Call-Info                     purpose             Yes       [RFC3261]

###

Similarly for draft-ietf-bliss-call-completion:

###

12.4. Call-Completion purpose parameter value

   This specification adds a new predefined value "call-completion" for
   the "purpose" header field parameter of the Call-Info header field.
   This modifies the registry header field parameters and parameter
   values by adding this RFC as a reference to the line for header field
   "Call-Info" and parameter name "purpose":

   Header Field: Call-Info

   Parameter Name: purpose

   Predefined Values: yes

   Reference: [RFC3261].[RFC5367][[RFC XXXX]]

   (Note for RFC Editor: Please fill in XXXX with the RFC number of this
   specification)

###

While it would be nice if RFC 3261 defined the registration rules a
bit more clearly, I suppose the current model is working fine and is
used for a wide variety of header field parameters for SIP header
field. If it's not broken, don't fix it. :-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Mar 2013 03:07:22 +0800

Yeah, sorry. I wasn't thinking. This is covered by RFC3968.
You just need an RFC with IANA considerations add the new entry to the 
existing table. It doesn't need to be done in sipcore. Feel free to do 
it in XMPP, or as AD-sponsored.

	Thanks,
	Paul

On 3/6/13 2:51 AM, Peter Saint-Andre wrote:
> iQIcBAEBAgAGBQJRNj6hAAoJEOoGpJErxa2pYacP/3Gsf5zn19Hs5r4+1POQISy0
> K6ZtaQMz7gITcv+q2LWNhLP5KQDhG4OkAWrLoP6UarcggEfToOaD5pUPovXf3S0U
> kzNGZ3nFK4T2o3ave1omfJiCyoyuxVirHE2nOsVFmie1c92cRywzNO+d1lq7V7H1
> UsDwpCigxsS3UcUFGgD+lv0uCIA8b2Dm2wCygZ5LTLbD9JJWsZinJ+GLRbMz0/ml
> GH45ydeS3oKqa6IPgDG8HggH9gjqNhdDYmNTrkcSb58rR6m8OOCka7EJpGbdRp2x
> XLb8uw24Eo0tKZ65SbCiTGKvlk0km0KheqAa0fo998+sNKCCbo/saz+HtBRSLOy0
> y8W8UOPS4JXM13UAzY8yVoaqkzmOsRprnM6sQ3uhtZkFUCjlmAjBqkK74yo9YkRZ
> R5VuK5MhE9BD7AsDW+zRbOaxSAIy3/8gr/hzJHuUqXYpoLn1O6BtycxIoqyc4jj1
> LyGEv/4LGw/Fz2th18k0+q+CTh/puN3IyAZLUDdo7l+ucl7BwHLV/FE03wlD9MvF
> V3TQuKFgjMZdP6KwcQgXsCiZvslAKfVYsn8kIMLP7pYj4xKSWoGXiN5AE5cz4xC/
> CVhWxX0WpocGWO/WzXtvzC705l8TqF8E/ydAyl+A722tsLwuV/JLb818khDreYog
> pF7vQfhYDOxU3AjJ1Bvu
> =NwTt

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Mar 2013 12:44:11 -0700

On 3/5/13 12:07 PM, Paul Kyzivat wrote:
> Yeah, sorry. I wasn't thinking. This is covered by RFC3968. You
> just need an RFC with IANA considerations add the new entry to the 
> existing table. It doesn't need to be done in sipcore. Feel free to
> do it in XMPP, or as AD-sponsored.

Yep. I'll submit something when the window opens and we'll take it
from there (AD-sponsored seems fine to me but we'll see what the ADs
have to say).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 5 Mar 2013 21:42:57 +0100

This applies if you do not want to change the registration policy for individual values from RFC 3968.

Keith

> Sent: 05 March 2013 19:44
> To: Paul Kyzivat
> Cc: [email-masked]
> iQIcBAEBAgAGBQJRNksLAAoJEOoGpJErxa2pjS0P/15+5WcZXGYnesWyZqBeDoku
> Iw5JIW7oZksrqJYfqBkz16ImjAV4YpRU2Lhe+DJrhH0Ci4xZxd/StLLnwYQE7FNy
> YU2kYZrAI0XMww4zK4wDSj979p/tAJYsJkjMVHhwJsfKkH2R+G7aBxUlox0SqDJ3
> 3lR6cnBm3HidQlDGYBI32gwHNbCoLTL8MA4BGU0hvpJVa6d6ikEfrbJRFYIi0Hri
> eyIcH8aWvwLGcEM9To1E6BlhtaYMYQ4riAB/IjcdjJ9uD1QmCD8iDQY7MrYLRGpp
> LD3VpGRuAVP7mm4Yj3IaNK2GdrvKZIMgVAyc2LpGXx9d5JFtu+trw3+YYu4tznB0
> FZBh5UbdPLq3CK3sYJJ7+q3soWkLHMylXik1BgEy5LTaOW6tWzDH5Gzp4Hxt53YD
> g88bBzSwQflftbFOHoCAAIiBacs9omyeil0hGafrPifPHd2mF4Ktb2O9FrykI8+2
> eusho5xqMsrAU81YcpNemnAiHTeLPSc4t/V0i7dZGeewORtUc8FI5qb3Zt1wTjSk
> g4zUf4eySyAH4Sec0iP6o8SNm/neYeEtVl+oXHGcQa0OdnUXIRS5+cKZYbCgcV0E
> Gz5vSFDXZQGlImPjZn93LNdgjyceA/32x3ClSecmLGflXuQoDOztfzCVHpAj36Ez
> sNSQhYGxL6G2aeGrZuo2
> =XeZm

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Mar 2013 04:56:09 +0800

> from there (AD-sponsored seems fine to me but we'll see what the ADs

I've seen mention of using this either to include an xmpp URI or an http 
reference to a vcard. Is the plan for on, the other, or both?

	Thanks,
	Paul

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sun, 10 Mar 2013 22:46:37 +0000

> submission window opens again.

Thank you - I think that this was an oversight in 3261 that it failed to define it and short draft could clean that up.  If the ADs are OK with it, this seems like a good draft to be AD sponsored.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 10 Mar 2013 22:28:43 -0400

> is just spec required so I think think you might be able to trivial add a "impp" purpose. 

https://datatracker.ietf.org/doc/draft-saintandre-impp-call-info/

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 12 Mar 2013 01:34:59 +0000

> https://datatracker.ietf.org/doc/draft-saintandre-impp-call-info/

Looks good to me