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
