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
On Wed, Oct 29, 2008 at 9:52 AM, Elwell, John <john.elwell@xxxxxxxxxxx> wrote:
>
> 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: sipping-bounces@xxxxxxxx
> > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of John-Luc Bakker
> > Sent: 28 October 2008 18:29
> > To: sipping@xxxxxxxx
> > Subject: draft-ietf-sipping-update-pai-07: allow
> > use of service URNs per RFC 5031
> >
> > 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
> > Use sip@xxxxxxxx for new developments of core SIP
> >
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
