Request to register "sipTrunkingCapability" link relation type

[deengi1]

Please confirm that:

• You have read and understood the requirements for registration.
• You have checked the registry and found no current link relation types that meet your needs.
• Your specification reference URL is stable; ideally, managed by a widely-recognised standards development organisation (e.g., published as an RFC). Otherwise, please give additional information.

If so, please enter the details of the link relation type below:

• Relation Name: sipTrunkingCapability
• Description: A capability document that defines parameters or configuration requirements for automated peering and communication channel negotiation of the Session Initiation Protocol (SIP).
• Reference: https://datatracker.ietf.org/doc/html/draft-engi-siptrunkingcapability-link

Any additional information (this will not be included in the registry)?
The ASAP working group has been chartered to standardize a configuration workflow to enable enterprise Session Initiation Protocol (SIP) networks to solicit the capability set of a SIP service provider network. The capability set can subsequently be used to configure features and services on the enterprise edge element, such as a Session Border Controller (SBC), to ensure smooth peering between enterprise and service provider networks. The basis of this channel negotiation relies on the exchange of a capability set document between devices to streamline configuration requirements gathering for the peering process. We are requesting the registration of a "sipTrunkingCapability" link type that would contain parameters and configuration requirements to allow this level of automated peering. Please let us know if there is any technical rigor that we can provide or proposed changes to the reference draft.

For further reference, the ASAP draft for automating SIP trunking is available here: https://datatracker.ietf.org/doc/html/draft-ietf-asap-sip-auto-peer

[mnot]

Hi Derek,

I'm going to put this on hold until the document gets adopted into an IETF stream, when we'll register as Provisional; once it's published as a standards-track RFC, we can shift it to Permanent.

[deengi1]

Hi Mark, just wanted to follow up on this link relation type. The ASAP working group has adopted the draft as of 9/30:

https://datatracker.ietf.org/doc/html/draft-ietf-asap-siptrunkingcapability-link

Thanks!

[mnot]

Thanks. I'll request registration with the following edit, to conform better to the prevailing style:

A capability document that defines parameters or configuration requirements for automated peering and communication channel negotiation of the Session Initiation Protocol (SIP).

refers to a capability document that defines parameters or configuration requirements for automated peering and communication channel negotiation of the Session Initiation Protocol (SIP).

[mnot]

Also, note that we'll be registering siptrunkingcapability not sipTrunkingCapability (the RFC requires lowercase). Is that acceptable, or would you like to use a delimiter -- e.g., sip-trunking-capability?

[evert]

Is it a bit weird that the link relationship includes the protocol 'sip'. Shouldn't this be generic + a 'type' to indicate the format; or has that ship sailed with link relationships.

[deengi1]

@mnot - The all lowercase "siptrunkingcapability" works for us and registration style change looks good, thanks.

@evert - This link relationship is tied to a very specific SIP trunking use case under development with the ASAP working group. The relationship name was chosen to be specific as such. Here is a link to the draft if you are interested in taking a look at the use case for SIP auto peering - https://datatracker.ietf.org/doc/html/draft-ietf-asap-sip-auto-peer

[evert]

@deengi1 fair enough, I'm pretty far removed from the domain so I wouldn't really be able to recommend a generalized version.

But for the sake of the argument, could it look like this, and why not?

{
  "rel" : "capability",
  "href" : "https://capserver.ssp1.com/capserver/capdoc.json",
  "type": "application/peering-info+json"
}

[deengi1]

It could look like that, however, "capability" seems extremely generic - in the context of real-time communications - capability could mean many things - media capabilities (codecs, frame-rates, encryption etc.), signaling capabilities (support for extensions of baseline SIP), security capabilities (signaling and media encryption, SDES/DTLS-based media encryption) etc. etc. The term "siptrunkingcapability" - for people well-versed with SIP trunking, is descriptive enough to convey that this link-relation can be used for all the usual capabilities attached to SIP trunking - ITSP SIP server(s), credentials, media, signaling, security, extension support etc.

[evert]

@deengi1 I understand but all that additional meaning can/should be conveyed with the media type. As a comparison, take the author rel. It tells a consumer that they can follow the link to find more information about the author. It doesn't say what kind of format or the shape of the document at the target.

The most egregious part of this rel is probably the sip part. Looking at the list, there are other relationships that also embed a protocol such as openid2.provider, P3Pv1 and amphtml, but I would argue that these are also all wrong.

To me the standard link relationships should convey the conceptual relationship between 2 resources, but not say anything about the protocol. That's what type is for.

Anyway, just my 2 cents.