A Session Initiation Protocol (SIP) Extension for the Identification of Services
draft-drage-sipping-service-identification-05

[Ballot comment]
4.  Syntax of the Header Fields

  The following syntax specification uses the augmented Backus-Naur
  Form (BNF) as described in RFC 4234 [RFC5234].

Typo: RFC 5234


6.  Examples of Usage

    * F4  proxy.example.com -> proxy.pstn.example (trusted)

    INVITE sip:+14085551212@proxy. pstn.example SIP/2.0
    Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
    Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc
    To:
    From: "Anonymous" ;tag=9802748
    Call-ID: 245780247857024504
    CSeq: 2 INVITE
    Max-Forwards: 69
    P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1

Should there be a Service-ID reserved for use in examples?



The following used to be a DISCUSS:

1).
4.2.  The P-Preferred-Service Header

  There may be multiple P-Preferred-Service header fields.  The
  semantics of multiple P-Preferred-Service header fields appearing in
  the same request is not defined.

What is the reason for allowing multiple header fields and not specifying their handling?
Lack of clarity here might affect interoperability.

[Ballot comment]
4.  Syntax of the Header Fields

  The following syntax specification uses the augmented Backus-Naur
  Form (BNF) as described in RFC 4234 [RFC5234].

Typo: RFC 5234


6.  Examples of Usage

    * F4  proxy.example.com -> proxy.pstn.example (trusted)

    INVITE sip:+14085551212@proxy. pstn.example SIP/2.0
    Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
    Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc
    To:
    From: "Anonymous" ;tag=9802748
    Call-ID: 245780247857024504
    CSeq: 2 INVITE
    Max-Forwards: 69
    P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1

Should there be a Service-ID reserved for use in examples?

[Ballot discuss]
I am thinking about voting Abstain on this document. However before I
decide I think the following minor issues needs to be fixed (as RFC Editor notes or otherwise):

1).
4.2.  The P-Preferred-Service Header

  There may be multiple P-Preferred-Service header fields.  The
  semantics of multiple P-Preferred-Service header fields appearing in
  the same request is not defined.

What is the reason for allowing multiple header fields and not specifying their handling?
Lack of clarity here might affect interoperability.

[Ballot discuss]
[revised discuss to reflect discussion on the telechat]

draft-ietf-sipping-service-identification makes a strong argument that derived service
identification is safe, and declarative service identification is perilous.  This document
includes both forms of service identification, although there are some constraints regarding
the applicability of declarative service identification.  A pointer (perhaps in the introduction)
to the wg document with an initial note regarding wg consensus on the risks of declarative
service identification would help resolve the disconnect between these two documents.

[Ballot discuss]
This is a discuss-discuss.  I will move to Abstain if the sponsoring AD prefers to
proceed with publication as Informational.

draft-ietf-sipping-service-identification makes a strong argument that derived service
identification is safe, and declarative service identification is perilous.  This document
includes both forms of service identification, although there are some constraints regarding
the applicability of declarative service identification.

Given the disconnect, would it be better to publish this document as experimental?  (Or are
there IANA considerations that preclude publishing as experimental?) 

I do not feel strongly enough to block publication, but it does seem a bit odd that we could
approve two conflicting specifications on the same telechat...

[Ballot discuss]
This is a discuss-discuss.  I will probably move to Abstain if the sponsoring AD prefers to
proceed with publication as Informational.

draft-ietf-sipping-service-identification makes a strong argument that derived service
identification is safe, and declarative service identification is perilous.  This document
includes both forms of service identification, although there are some constraints regarding
the applicability of declarative service identification.

Given the disconnect, would it be better to publish this document as experimental?  (Or are
there IANA considerations that preclude publishing as experimental?) 

I do not feel strongly enough to block publication, but it does seem a bit odd that we could
approve two conflicting specifications on the same telechat...

[Ballot discuss]
This is a discuss-discuss.  I will probably move to Abstain if the sponsoring AD prefers to
proceed with publication as Informational.

draft-ietf-sipping-service-identification makes a strong argument that derived service identification is safe, and declarative service identification is perilous.  This document
includes both forms of service identification, although there are some constraints regarding
the applicability of declarative service identification.

Given the disconnect, would it be better to publish this document as experimental?  (Or are
there IANA considerations that preclude publishing as experimental?)

I do not feel strongly enough to block publication, but it does seem a bit odd to approve
two conflicting specifications on the same telechat...

IANA comments:

ACTION 1:

Upon approval of this document, IANA will make the following
assignments in the Header Fields registry at
http://www.iana.org/assignments/sip-parameters

Header Name compact Reference
----------------- ------- ---------
P-Asserted-Service [RFC-drage-sipping-service-identification-03]
P-Preferred-Service [RFC-drage-sipping-service-identification-03]


ACTION 2:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/sip-parameteres

Registry Name: Service-ID/Application-ID Labels
Registration Procedure: Specification Required
Initial contents of this registry will be:

Initial Contents of the Registry:
Service/Application Reference Description
--------------------------------------------------------------------
3gpp-service [RFC-drage-sipping-service-identification-03]
Communication services defined by
3GPP for use by the IM CN subsystem
and its attached UAs. This value
in itself does not define a service
and requires subsequent labels to
define the service.

3gpp-application [RFC-drage-sipping-service-identification-03]
Applications defined by 3GPP for
use by UAs attached to the IM CN
subsystem. This value in itself
does not define a service and
requires subsequent labels to define
the service.

[Ballot comment]
4.  Syntax of the Header Fields

  The following syntax specification uses the augmented Backus-Naur
  Form (BNF) as described in RFC 4234 [RFC5234].

Typo: RFC 5234


4.2.  The P-Preferred-Service Header

  Table 2 extends the headers defined in this document to Table 2 in

I think you mean "adds the headers defined ...".

  SIP [RFC3261], Section 7.1 of the SIP-specific event notification
  [RFC3265], tables 1 and 2 in the SIP INFO method [RFC2976], tables 1
  and 2 in Reliability of provisional responses in SIP [RFC3262],
  tables 1 and 2 in the SIP UPDATE method [RFC3311], tables 1 and 2 in
  the SIP extension for Instant Messaging [RFC3428], table 1 in the SIP
  REFER method [RFC3515] and tables 2 and 3 in the SIP PUBLISH method
  [RFC3903]:

6.  Examples of Usage

    * F4  proxy.example.com -> proxy.pstn.example (trusted)

    INVITE sip:+14085551212@proxy. pstn.example SIP/2.0
    Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
    Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc
    To:
    From: "Anonymous" ;tag=9802748
    Call-ID: 245780247857024504
    CSeq: 2 INVITE
    Max-Forwards: 69
    P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1

Should there be a Service-ID reserved for use in examples?

[Ballot discuss]
I am thinking about voting Abstain on this document. However before I
decide I think the following minor issues needs to be fixed (as RFC Editor notes or otherwise):

1).
4.2.  The P-Preferred-Service Header

  There may be multiple P-Preferred-Service header fields.  The
  semantics of multiple P-Preferred-Service header fields appearing in
  the same request is not defined.

What is the reason for allowing multiple header fields and not specifying their handling?
Lack of clarity here might affect interoperability.

2).
4.4.  Registration Template

  Declared registrant of the namespace:  TBD

Who is the registrant of the namespace?

IANA Last Call Comments:

*** We would like authors to confirm if
*** we understood correctly.

Upon approval of this document, the IANA will make
the following assignments in the xxx" registry
located at

http://www.iana.org/assignments/example-foobar-registry
sub-registry "yyy"

Action #1:
Upon approval of this document, the IANA will make
the following assignments in the "Session Initiation
Protocol (SIP) Parameters" registry located at

http://www.iana.org/assignments/sip-parameters
sub-registry "Header Fields - per [RFC3261] Section 27.3"

Header Name ! compact | Reference
--------------------+---------+---------
P-Asserted-Service + + [RFC-drage-sipping-service-
identification-00]
P-Preferred-Service + + [RFC-drage-sipping-service-
identification-00]


Action #2:
Upon approval of this document, the IANA will in
the following registry "Session Initiation Protocol
(SIP) Parameters" located at

http://www.iana.org/assignments/sip-parameters
create a new sub-registry "Service-ID Labels
[RFC-drage-sipping-service-identification-00]"

Registration policy: Specification Required

Format of this sub-registry will be:

Service | Reference | Description
--------+-----------+-------------------------------------------------
foo | RFCxyz | Brief description of the 'foo' service

The registry will not contain any registrations
upon creation.


We understand the above to be the only IANA Actions
for this document.