Subject: [SIP] Also field

From: "Vijeth D" <[email-masked]>
Date: 5 Jan 2001 06:14:47 -0000

Hi,
  The syntax of the also header field is not very clear.
Also = ”Also” ”:” 1# (( name-addr — addr-spec )

First of all a closing parantheses is missing and secondly what is the meaning of a '-' between name-addr and addr-spec?

Thanks,

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Jeff Mark" <[email-masked]>
Date: Fri, 5 Jan 2001 09:00:04 -0800

This is what I see as the syntax from section 6.11 of the Nov 24
draft-ietf-sip-rfc2543bis-02.txt:

	Also  =  "Also" ":" 1# (( name-addr | addr-spec )

And, I thought the BYE/Also mechanism for Transfer was deprecated in
favor of the REFER method so I'm a bit confused on why it has appeared
in the bis draft.  Can anyone refresh my memory?

Thanks,

-Jeff

From: Vijeth D [mailto:[email-masked]]
> First of all a closing parantheses is missing and secondly
> what is the meaning of a '-' between name-addr and addr-spec?
>
> Thanks,
>

---

From: Billy Biggs <[email-masked]>
Date: Fri, 5 Jan 2001 12:17:19 -0500 (EST)

> in the bis draft.  Can anyone refresh my memory?

  Since everyone has implemented it, the suggestion was to add it to the
bis.  However, many people have objected, and it will likely be removed.

--
Billy Biggs                         [email-masked]
http://www.div8.net/billy       [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 05 Jan 2001 12:15:57 -0500

> in the bis draft.  Can anyone refresh my memory?

It was requested as reflecting current implementation practice. The idea
of putting things into the draft (it being called a draft...), is to get
people to speak up and complain. Otherwise, nothing ever gets settled.

I suppose there are two solutions:

- Remove Also as duplicating REFER (whatever it's final shape turns out
to be). This follows the "one-task, one-approach" rule. 

- If REFER turns into a monster protocol that requires SUBSCRIBE,
NOTIFY, XML parsing and who knows what else for a simple blind transfer,
then I suspect that many implementations will use it regardless of what
the bis spec says or doesn't say.

Thus, I think it's time to arrive at some closure on the REFER issue. In
my personal opinion, NOTIFY (with the status responses as a message/sip
body rather than some new message format) and implied subscription seems
to be a reasonable compromise between complexity and generality,
possibly with some hint in the request as to whether notifications are
desired or not.

To muddy the water a bit more with an unrelated topic, I wonder if some
of the ugliness of encoding methods and headers in the Refer-To URL
could be avoided by also attaching the message to be generated as a
message/sip body.

Henning

---

From: Rick Dean <[email-masked]>
Date: Fri, 5 Jan 2001 12:10:00 -0600

> possibly with some hint in the request as to whether notifications are

A re-INVITE with a Refer-Status: header is easier to code 
and parse.  The (single-part) body can then contain SDP.
It will all fit inside of a non-fragmented datagram.
More importantly, the response to the re-INVITE can be
a 180 ringing as need be.

--
Rick
[email-masked]

---

From: Sean Olson <[email-masked]>
Date: Fri, 05 Jan 2001 15:57:27 -0600

> could be avoided by also attaching the message to be generated as a

I second that idea -- at least as an option in the absence of a Refer-To 
URL.
It also opens the door for nice things like S/MIME.
/sean

---

From: "Robert Sparks" <[email-masked]>
Date: Mon, 8 Jan 2001 08:52:42 -0600

This doesn't extend to many non-sip URLs.

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Friday, January 05, 2001 3:57 PM
> To: Henning Schulzrinne
> Cc: Jeff Mark; 'Vijeth D'; [email-masked]
> Subject: Re: [SIP] Also field
> 
> 
> 
>

---

From: Sean Olson <[email-masked]>
Date: Mon, 08 Jan 2001 13:34:05 -0600

Correct. This is not a general solution that works for
everything. But I still think it is a useful option to
avoid 2K URIs (an exaggeration of course) :)

/sean

Robert Sparks wrote:

>>> To muddy the water a bit more with an unrelated topic, I 
>> 
>> wonder if some
>>