Subject: [Sipping] draft-ietf-sipping-update-pai-07: allow use of service URNs per RFC 5031

From: "John-Luc Bakker" <[email-masked]>
Date: Tue, 28 Oct 2008 13:29:01 -0500

Hi John, SIPPING-ers,

draft-ietf-sipping-update-pai-07 mentions that P-Asserted-Identity
header field values with unexpected URI schemes should be ignored.
Furthermore, only SIP, SIPS and tel are expected URI schemes.

RFC 5031 introduces service URNs allowing well-known context-dependent
services to be resolved. If a well-known content-dependant service
populates a P-Asserted-Identity header field or a proxy populates it
on behalf of the service, how should the header field be populated? It
would be useful if the service URN is allowed as an entry into the
P-Asserted-Identity.

Would allowing service URNs in the P-Asserted/Preferred-Identity
header field be a useful addition to this draft?

Regards,

            John-Luc
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 29 Oct 2008 14:52:39 +0000

John-Luc,

Sounds like a good idea to me. First, we need to check whether the
existing ABNF in RFC 3325 permits URNs, and if so make it clear in the
update-pai draft that receipt of a service URN should be tolerated.
Second, we need to permit the sending of a service URN. Comments?

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of John-Luc Bakker
> Sent: 28 October 2008 18:29
> To: [email-masked]
> Subject: [Sipping] draft-ietf-sipping-update-pai-07: allow 
> use of service URNs per RFC 5031
> 
> Hi John, SIPPING-ers,
>

---

From: "John-Luc Bakker" <[email-masked]>
Date: Thu, 30 Oct 2008 12:32:34 -0500

John,

I checked and RFC 3325 does permit "absoluteURI" with "opaque-part".
The rules following "absoluteURI" would seem to allow service URNs.

A question to resolve would be answering how many URIs can be
contained in parallel. In text below I propose not to change the limit
of 2. The motivation for not allowing SIP, SIPS and URN with service
URN label in parallel: since a service URN was designed to be
univerally resolveable, advertising a SIP/S URI along with a service
URN seems to defeat the purpose of being assigned a service URN.

Perhaps text permitting use of service URNs, as registered in the IANA
registry for service URN labels, could read as follows:

[start old text]
   This document does not change the RFC 3325 requirement that allows
[..]
   o  ignore a SIP URI if a SIPS URI occurred earlier in the header
      field and vice versa.
[end old text]

[start new text]
   This document does not change the RFC 3325 requirement that allows
   each of these header fields to contain at most two URIs. This
document does allow one URI to be either
   a SIP, a SIPS URI or a URN with Service URN Label, as registered in
the IANA registry for service URN labels,
   and the other is a tel URI. Future updates to this document may
relax these requirements further.  The
   requirement above means that an entity receiving a request
containing a P-Asserted-Identity or P-Preferred-Identity
   header field must act as follows:

   o  ignore any URI with a scheme other than SIP, SIPS, URN Service
Labels or tel;

   o  ignore a second or subsequent URN with Service URN Label, a
second or subsequent SIP URI, a second or subsequent SIPS
      URI or a second or subsequent tel URI; and

   o  ignore a URN with Service URN Label if a SIP URI or a SIPS URI
occurred earlier in the header field, ignore a SIP URI if a SIPS URI
or a URN with Service URN Label occurred earlier in the header field,
ignore a SIPS URI if a SIP URI or a URN with Service URN Label
occurred earlier in the header field.
[end new text]

Comments?

John-Luc