Re: [sipcore] sipcore Digest, Vol 168, Issue 11

[Pierce Gorman <[e-mail]>]

+1


-----Original Message-----
From: sipcore <[e-mail]> On Behalf Of [e-mail]
Sent: Thursday, August 17, 2023 2:00 PM
To: [e-mail]
Subject: sipcore Digest, Vol 168, Issue 11

Send sipcore mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/sipcore
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific than "Re: Contents of sipcore digest..."


Today's Topics:

   1. Re: Establishing an IANA registry for Call-Info protocol
      parameter values (Dale R. Worley)


----------------------------------------------------------------------

Message: 1
Date: Thu, 17 Aug 2023 12:05:23 -0400
From: [e-mail] (Dale R. Worley)
To: [e-mail], [e-mail]
Subject: Re: [sipcore] Establishing an IANA registry for Call-Info
	protocol parameter values
Message-ID: <[e-mail]>

"Olle E. Johansson" <[e-mail]> writes:
>> On 8/16/23 6:23 PM, Brian Rosen wrote:
>>> As I said, we have several defined in emergency services, and wished 
>>> we had a registry to declare them.  There are no RFCs that define 
>>> them, but there are published, referenceable standards.
>> 
>> Hmm. That puts an interesting spin on this. If those defs aren't in 
>> the RFCs that are currently referenced in the existing registry, then 
>> there is no way for a party unaware of them to discover those values. 
>> And, in the future, somebody else intending to define a new value 
>> might accidentally reuse one of your existing values!
>> 
> Brians information is a clear indication that we need the registry for 
> interoperability. Agree fully with Paul here.

Certainly, we need a way to document values used in the field for emergency services.

I checked to see whether a "grep" would turn up a list of the defined values by searching for examples of usage.  What that delivers is:

$ grep 'Call-Info.*purpose=' ...
./rfc3261.txt:   Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
./rfc6910.txt:   Call-Info: monitor-URI;purpose=call-completion;m=XX
./rfc6910.txt:         | Call-Info:<sip:[e-mail]>;purpose=call-completion;m=NR
./rfc6910.txt:   a Call-Info header field with "purpose=call-completion".  The
./rfc6993.txt:   Call-Info: <xmpp:[e-mail]> ;purpose=impp
./rfc7081.txt:   Call-Info: <xmpp:[e-mail]> ;purpose=impp
./rfc8688.txt:   Call-Info: <https://block.example.net/complaint-jws>;purpose=jwscard
./rfc8876.txt:      Call-Info: cid:[e-mail];purpose=EmergencyCallData.cap

that is, the 5 values "icon", "call-completion", "impp", "jwscard", and "EmergencyCallData.cap" out of the 8 RFCs that are on record.

An additional 5 values are defined:  "card" is defined in RFC 3261, "list-management" is defined in RFC 5367, "ccmp" is defined in RFC 7082, the pattern "EmergencyCallData.*" in RFC 7852, and "rue-owner" in RFC 9248.

So I'd say that it's time we created a sub-registry to log these values, because there's no way to locate the specification for any particular value that doesn't require human intervention, nor for a list of defined values.

Dale



------------------------------

Subject: Digest Footer

_______________________________________________
sipcore mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sipcore


------------------------------

End of sipcore Digest, Vol 168, Issue 11
****************************************