Subject: RE: [Sip] RE: Contact header in PUBLISH

From: "Chris Boulton" <[email-masked]>
Date: Wed, 10 Dec 2003 14:57:56 -0000

I think the 'MAY' option does provide more scope for future extensions.
You might see a contact, but ignore it.  I understand what Keith is
saying BUT there is the danger of implementations rejecting on SHOULD
NOT, even though this is wrong. 

>-----Original Message-----
>From: Drage, Keith (Keith) [mailto:[email-masked]]
>Sent: 10 December 2003 14:50
>To: [email-masked]'; Drage, Keith (Keith);
>[email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: RE: [Sip] RE: Contact header in PUBLISH
>
>But Paul's text does not disallow, it says SHOULD NOT, not MUST NOT, so
all
>recipients must cater for its inclusion, even if they have no use for
it.
>
>regards
>
>Keith
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: 10 December 2003 14:31
>> To: [email-masked]; [email-masked]; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: RE: [Sip] RE: Contact header in PUBLISH
>>
>>
>>
>>
>> > -----Original Message-----
>> > From: ext Drage, Keith (Keith) [mailto:[email-masked]]
>> > Sent: 10.December.2003 13:39
>> > To: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki);
>> > [email-masked]
>> > Cc: [email-masked]; [email-masked]
>> > Subject: RE: [Sip] RE: Contact header in PUBLISH
>> >
>> >
>> > If we identify another usage for this header in the future,
>> > then presumably we need to write another RFC to do it
>> > superceding the current PUBLISH RFC either fully or in part.
>> >
>> > The question we therefore need to ask is whether either text
>> > has compatibility problems with such a future extension, and
>> > I believe the answer is no.
>>
>> If one RFC disallows something and an extension to it allows
>> the exact same thing that is disallowed, then we have a
>> problem. If something is disallowed, it should stay that way,
>> even in extensions.
>>
>> >
>> > I therefore prefer Paul's text, as it leaves fewer unanswered
>> > questions as to whether I put it in now or not. As regards
>> > Hisham's current text, I am left with the question of whether
>> > I should put it in just in case.
>>
>> My text (well, Aki's) is clear, you may put contact-header,
>> but it doesn't buy you anything. Common sense will tell
>> someone not to include it. Even if you include it, so what?
>>
>> Regards,
>> Hisham
>>
>> >
>> > regards
>> >
>> > Keith
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: [email-masked]
>> [mailto:[email-masked]]
>> > > Sent: 10 December 2003 11:32
>> > > To: [email-masked]; [email-masked]
>> > > Cc: [email-masked]; [email-masked]
>> > > Subject: RE: [Sip] RE: Contact header in PUBLISH
>> > >
>> > >
>> > > You never know what us geniuses might come up with in the
>> > > future as a possible use for contact-header in PUBLISH. why
>> > > eliminate this possibility. Including a contact- header in
>> > > PUBLISH does not break the protocol, so no need to explicitly
>> > > disallow it. I vote for Aki's original suggestion of using
>> > > MAY with a slight modification:
>> > >
>> > > 	PUBLISH request MAY include a Contact header field,
>> > > although doing so
>> > > 	has no meaning in the PUBLISH context **as defined in
>> > > this specification**.
>> > >
>> > > Regards,
>> > > Hisham
>> > >
>> > > > -----Original Message-----
>> > > > From: [email-masked] [mailto:[email-masked]]On Behalf
>> > > > Of ext Aki
>> > > > Niemi
>> > > > Sent: 09.December.2003 18:49
>> > > > To: ext Paul Kyzivat
>> > > > Cc: [email-masked]; [email-masked]
>> > > > Subject: Re: [Sip] RE: Contact header in PUBLISH
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > ext Paul Kyzivat wrote:
>> > > > > [email-masked] wrote:
>> > > > >
>> > > > >>
>> > > > >> PUBLISH is generally never sent in the "other" direction,
>> > > > so I don't
>> > > > >> see any reason not to say:
>> > > > >>
>> > > > >>     PUBLISH request MAY include a Contact header field,
>> > > > although doing so
>> > > > >>     has no meaning in the PUBLISH context.
>> > > > >>
>> > > > >> Any other opinions?
>> > > > >
>> > > > >
>> > > > > How about another phrasing that says the same thing but
>> > > > emphasizes the
>> > > > > desired behavior?
>> > > > >
>> > > > >        PUBLISH request SHOULD NOT include a Contact
>> > header field.
>> > > > >        Including one has no meaning in the PUBLISH context.
>> > > >
>> > > > I'm OK with that, although my understanding is that if we
>> > > use SHOULD
>> > > > NOT, we should be attaching some description of the
>> > > > circumstances where
>> > > > it would be OK to include it.
>> > > >
>> > > > Cheers,
>> > > > Aki
>> > > >
>> > > > >
>> > > > > Paul
>> > > > >
>> > > >
>> > > > _______________________________________________
>> > > > 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
>> > > >
>> > >
>> > > _______________________________________________
>> > > 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
>> > >
>> >
>>
>
>_______________________________________________
>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

This message has been scanned for viruses by MailControl - www.mailcontrol.com

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Dec 2003 16:24:03 -0500

I think this has received way more cycles than it needs.
I am happy with either MAY or SHOULD NOT.
Perhaps the argument Aki raised (that SHOULD NOT needs to be accompanied 
by an explanation of the kinds of exceptions that are ok) is a reason to 
prefer MAY. (I don't think we have a prayer of defining the 
circumstances when it might be acceptable.)

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Dec 2003 16:35:59 -0500

Here's my two cents.

I also prefer SHOULD NOT. Indeed, that is the text currently written 
into the gruu spec when it discusses inclusion of the gruu parameter 
in a REGISTER. Like the Contact in PUBLISH, it is ignored by the 
server. Here is the text:

> Specifically, the Contact URI in the REGISTER request
> SHOULD NOT contain the gruu Contact header field parameter. Any such
> parameters are ignored by the registrar, as the UA cannot propose a
> GRUU for usage with the Contact URI.

I chose SHOULD NOT, since the question was raised on the list about 
whether or not the server would honor the request for the parameter. 
Adding these words makes the intent really clear. I think its 
appropriate for cases where it seems like doing something will 
accomplish a particular behavior, but it won't or shouldn't.

MUST NOT is not appropriate, since violating the text will not cause 
interoperability failures or protocol problems, and thats my 
qualification level for MUST or MUST NOT.

The other choice that makes sense to me is to say NOTHING on the 
client side for publish about COntact, and say that a server MUST 
ignore any Contact present in a request. Thats more appropriate, I 
think, for cases where we don't think people will be confused and try 
to insert it to get a specific behavior.

-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