Document: draft-johnston-sip-osp-token-06.txt
Reviewer: Mary Barnes
Date: 15 september 2004 



Summary:
--------

Given that there are already 2 Discusses against this draft, it is
likely not ready for publication.

Prior to seeing the other discuss comments, my summary was going to
be that it is ready to publish as an Informational, given that it is
a defining a proporietary header (P-header) whose detailed usage and
applicability is specified in the referenced TIPHON specification.

However, as Ted points out in his discuss, there is normative
information from a protocol perspective on the processing of this
header that is missing (eg. how are forked INVITEs handled etc.) that
would now be required for a non "P" header specification in the SIP
WG. Unfortunately (or not) the precedent has been set in other
P-header specs (and actually some early SIP specs) for not fully
addressing all the aspects of processing a given header for situations
like forking (i.e. it's assumed that the description in RFC 3261 is
sufficient in terms of how each request is formed and what goes in
each request).

To understand how this should work, one needs to refer to the TIPHON
spec listed in the references. I'm not at all an expert in this area,
but fundamentally, I believe if you follow this model then you
include this token (that you MUST include in the initial INVITE
between domains) in all the INVITES just that it's available to the
other party between domains.

So, I think this comes back to a fundamental question as to how SIP
WG is handling P-headers and that is whether they must be as detailed
and accurate in specification as non P-headers(i.e. Standard's track
specs)? My understanding is that typically P-headers are being
defined to address concerns from other SDOs that are deemed too
specific to become general SIP extensions. Thus, complete
specification of their usage is left up to that specific SDO and IETF
is providing a means for registering those headers to reduce
interoperability collisions.

 I've copied Allison, since this is her document and perhaps she can
 clarify that for the group.



 Mary H. Barnes 
mary.barnes@nortelnetworks.com