Subject: RE: [Sip] RFC 3608 on Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration

From: "Chris Boulton" <[email-masked]>
Date: Thu, 9 Oct 2003 09:56:15 +0100

Dean, Bernie,

This may seem a silly question (I'm sure I will be told that it is ;-),
BUT I was wondering why the use of the 'Supported/Require' headers are
not required with this extension.

Regards,

Chris.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: 09 October 2003 01:01
>Cc: [email-masked]; [email-masked]
>Subject: [Sip] RFC 3608 on Session Initiation Protocol (SIP) Extension
>Header Field for Service Route Discovery During Registration
>
>
>A new Request for Comments is now available in online RFC libraries.
>
>
>        RFC 3608
>
>        Title:      Session Initiation Protocol (SIP) Extension Header
>                    Field for Service Route Discovery During
>                    Registration
>        Author(s):  D. Willis, B. Hoeneisen
>        Status:     Standards Track
>        Date:       October 2003
>        Mailbox:    [email-masked], [email-masked]
>        Pages:      17
>        Characters: 35628
>        Updates/Obsoletes/SeeAlso:    None
>
>        I-D Tag:    draft-ietf-sip-scvrtdisco-04.txt
>
>        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3608.txt
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 9 Oct 2003 11:56:43 +0200 (CEST)

Hi Chris,

Let me make a brief excursion to the history of Service-Route: I remember
some discussions concerning the possible usage of an option-tag for
(P-)Service-Route in the early stage of the I/D. At that time the working
assumption was, that this would be a P-header field
(i.e. P-Service-Route). Since you cannot Require a P-header field, the
discussion immediately ended at that time.

Lateron working assumption was changed: the P-header field was changed to
a normal header field. But nobody has brought up again a requirement
for an option-tag service-route.

In case such a requirement turns out be useful, we could consider to make
an additional document describing the Require/Supported behavior with
Service-Route.

What is your main motivation for such an option-tag for service-route?

cheers,
 Bernie

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 09 Oct 2003 14:12:55 -0400

You can't really add support for a Supported mechanism later, since 
you run into the problem that if Suported is missing from the 
REGISTER, you can't know if thats because service route isn't 
supported, or if it is supported but the new "add Supported to service 
route draft" is not supported.

The reason why Supported makes sense is, without it, the registrar has 
no way to know whether or not the UA will be able to process the 
Service-Route header field in the response. As such, it will end up 
always needing to insert it, even if none of the UAs understand it. 
THat is wasteful.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 10 Oct 2003 18:51:24 +0200 (CEST)

> route draft" is not supported.

IMHO there are ways to handle this, e.g. with local policy at the
Registrar.

The question, which remains:
Is there a requirement / use case for standardizing an option tag
"service-route" to be used in Supported and/or Require header fields?

If yes, we could have a closer look at the feasibility.

cheers,
 Bernie