[Sipping] The need for P-Preferred-Service (was RE: IETF last call comments ondraft-drage-sipping-service-identification)

["Elwell, John" <john.elwell at siemens.com>]

> -----Original Message-----
> From: sipping-bounces at ietf.org 
> [mailto:sipping-bounces at ietf.org] On Behalf Of DRAGE, Keith (Keith)
> Sent: 20 October 2008 18:43
> To: sipping at ietf.org
> Subject: [Sipping] IETF last call comments 
> ondraft-drage-sipping-service-identification
> 
> I have just posted an updated copy of
> draft-drage-sipping-service-identification with the partially resolved
> comments from the IETF last call (after an extended battle 
> with getting
> the referencing to work in xml2rfc).
> 
> The comments made, and the changes made, are summarised at:
> 
> http://www.softarmor.com/sipping/process/wg-review/reviews/ser
> vice-id-co
> mments.htm
> 
> Apart from confirming the validity of my responses to the 
> other comments
> there are essentially two comments outstanding:
> 
> 1)	as to whether the P-Preferred-Service header provides a valid
> mechanism with the constraints defined in this document.
[JRE] The document is certainly inconsistent. In section 1 it states:
"The use of these extensions is only applicable inside an
   administrative domain with previously agreed-upon policies for
   generation, transport and usage of such information."
and then in "In addition, this extension
   allows user agent clients outside the trust domain to provide a hint
   of the requested service."
which, assuming trust domain in this sentence equates to administrative
domain in the first quoted sentence, appears to be in contradiction. All
the stuff do to with P-Preferred-Service seems to be in contradication
to the first quoted sentence.

Then in section 2 it states "The use of these extensions is
   only applicable inside a 'Trust Domain' as defined in Short term
   requirements for Network Asserted Identity (see RFC 3324 [RFC3324])."
which again seems to be contradicated by the P-Preferred-Service parts.

Also the motivation for P-Preferred-Service seems rather weak. How can
it "assist", if the service is derivable from other information in the
request?

It seems to me that P-Preferred-Service does not add any value and
contradicts certain statements in the draft.

John
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP