Subject: Re: [RAI] RAI-ART review of draft-ietf-sipping-sip-offeranswer-13

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 May 2010 19:24:36 -0400

Ben Campbell wrote:
> I am the assigned RAI-ART reviewer for draft-ietf-sipping-sip-offeranswer-13.

Thanks Ben! (I don't envy you.)

> For background on RAI-ART, please see the FAQ at
> <http://www.softarmor.com/rai/art/FAQ.html>.
> 
> Please resolve these comments along with any other comments you may receive.
> 
> Summary:
> 
> This draft claims an intended status of "informational". I believe this needs to be standards track, or a BCP. For that purpose, I think it's on the right track, but I have some other minor comments and questions that I think should be addressed first.

See below.

> And BTW, I think this is a great document to have, as it is correct in pointing out our current offer/answer rules are scattered all over the place.
> 
> Major Comments:
> 
> 
> -- The draft is listed as informational, and goes to great lengths to pretend to make no normative changes. I am not convinced. There are a number of places where it has the practical effect of  updating or adding normative constraints to existing proposed standards. I think it would be best to make this standards or BCP track and drop the pretense of being non-normative.

Lets sort this one out first before worrying too much about the rest, 
because this has potential to cause a lot of changes.

When we first started working on this (five years ago) it was the intent 
and expectation that this would be an informative document. We have 
identified certain normative changes and deferred them to other 
documents, such as the reinvite draft.

I have certainly *tried* to draw the line so that if certain points are 
not explicit in normative RFCs, that at least they are corollaries that 
can be derived from the RFCs. In some cases I think this has been 
stretched a bit further to proofs by contradiction - where any other 
interpretation would lead to non-functional behavior and so must not 
have been intended. And then there are some places that really are BCP 
material in that they are of the form: the bad things that might happen 
won't if you behave in the following way.

In some sense it would be *easier* if this were a normative document, in 
that we would no longer have to find all those rationalizations. And 
maybe readers would prefer for it to be normative because they then 
could justify following this document without looking at the others for 
info on o/a. Yet, even if we were to make it a normative document, I 
think there would only be a *few* normative changes, and even those 
might be debated as not *really* being changes.

I'm not intimately familiar with the rules and applicability of BCPs. I 
gather if we went that way we can have normative language that adds to 
or tightens that in standards track RFCs, but can't do anything that 
loosens or contradicts such documents. Is that right?

So I would like some guidance here. I think it makes sense to at least 
move to BCP. But would it be better to do that, or go standards track?

	Thanks,
	Paul

> Minor Comments:
> 
> -- section 1.1: 
> 
> The need for normative language in a draft that states it is not making any normative changes is telling.
> 
> -- section 2.2, 5th paragraph, last sentence: "The 488 response is another proposed solution, UAS may respond with a 488 response and then UAC should send again a PRACK request without an offer."
> 
> What do you mean by "proposed solution"? Is this solution allowed, recommended, etc?
> 
> -- 2.2, Paragraph 8 (in NOTE):
> 
> Please elaborate on "401 response cannot be avoided". Perhaps something to the effect of "For example, the UAS may need to send an authentication challenge in a 401 response."
> 
> --2.2, paragraph 9:
> 
> Please elaborate on "...a UA should take care not to cause an infinite offer/answer loop."
> 
> -- 2.2, Table 2, (**)
> 
> Please elaborate -- how can a UA know the mind of the receiver?
> 
> -- 3.1.1
> 
> Are you certain there are no normative changes here? Can all the assertions be supported unambiguously by existing specs? 
> 
> -- UAC Behavior, item 1: "... not a real answer...
> 
> Does that make it a fake answer? I don't think "real" is the property you are looking for. Perhaps " not a final answer" or "preliminary answer" would be. Ore descriptive?
> 
> -- 3.1.1, paragraph before figure 1: "Therefore, a UAS should send a SDP answer reliably (if possible) before it starts sending media."
> 
> This  really sounds like either normative or BCP material.
> 
> -- 3.1.2, last paragraph, last sentence: "The UAC should take care to avoid this situation when it sends the INVITE request without SDP."
> 
> How? Are you suggesting that you shouldn't send an empty invite unless you can accept any answer without user intteraction?
> 
> -- section 4.1, paragraph after figure 4:
> 
> Can you elaborate on "should not send...at this point"? For example, should not send the reINVITE until...
> 
> Comment repeats for most of the following scenarios.
> 
> -- 5.1, first paragraph: "...without regard for what the other party in the call may have indicated previously."
> 
> This is not universally true. For example, the sender may have access to the recipient's presence information, which it generally shouldn't ignore.
> 
> 5.2.3, first paragraph: "The media lines that are accepted should typically be those with types and formats the UAS would have included if it were the offerer"
> 
> I'm not sure how to apply that advice to make any useful decision. For example, if I might not have offered video, should I reject a media stream in someone else's offer?
> 
> 
> 
> 
> Nits and Editorial Comments:
> 
> -- Please proofread for the following recurring errors: comma-spliced run-on sentences, missing articles, and incorrect selection of "a/an" vs "the".
> 
> -- s/"can not"/"cannot" throughout.
> 
> -- 3.1.1, figure 1:
> 
> The discussion talked about endpoints that do not support 100rel, but the example uses it.
> 
> -- 3.1.2, 2nd paragraph (Note): 
> 
> Please reference the figure number when you first start talking about messages from that figure.
> 
> -- 3.3, last paragraph, last sentence: "Otherwise, some 3pcc flows will break."
> 
> Expand 3pcc on first mention. Also, please provide a reference.
> 
> -- 3.4, first paragraph: "...newer specifications..."
> 
> Please specify which specs you are talking about.
> 
> -- 4, 3rd paragraph:
> 
> What do you mean by "...rules are guaranteed"?
> 
> No need for quotes around "exceptional".
> 
> I'm not sure what you mean by " carefully restricted in the RFCs" Are you suggesting a change in existing or future RFCs?
> 
> -- 4.2, paragraph after figure 11: "At best it..."
> 
> What is the antecedent for "it"?
> 
> -- 5.1, general:
> 
> I find it curious to ascribe wants and interests to the UA. This leads to some awkward constructions when discussing how a UA may not know what it wants. 
> 
> 
> 
> 
> 
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 24 May 2010 11:05:55 +0200

I have a distinct reluctance to go anywhere with this document that has any implications of a normative nature.

Essentially if as a result of the analysis of this document, we believe something needs fixing, then we should go back and create bis versions of RFC 3264 or RFC 3262. This is not an area where we need yet more add on specifications to what is already the supposed normative documents in this area.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Kyzivat
> Sent: Friday, May 21, 2010 12:25 AM
> To: Ben Campbell
> Cc: [email-masked]; [email-masked]
> Subject: Re: [RAI] RAI-ART review of 
> draft-ietf-sipping-sip-offeranswer-13
> 
> 
> 
> Ben Campbell wrote:
> > This draft claims an intended status of "informational". I 
> believe this needs to be standards track, or a BCP. For that 
> purpose, I think it's on the right track, but I have some 
> other minor comments and questions that I think should be 
> addressed first.
> 
> See below.
> 
> > And BTW, I think this is a great document to have, as it is 
> correct in pointing out our current offer/answer rules are 
> scattered all over the place.
> > 
> > Major Comments:
> > 
> > 
> > -- The draft is listed as informational, and goes to great 
> lengths to pretend to make no normative changes. I am not 
> convinced. There are a number of places where it has the 
> practical effect of  updating or adding normative constraints 
> to existing proposed standards. I think it would be best to 
> make this standards or BCP track and drop the pretense of 
> being non-normative.
> 
> Lets sort this one out first before worrying too much about 
> the rest, because this has potential to cause a lot of changes.
> 
> When we first started working on this (five years ago) it was 
> the intent and expectation that this would be an informative 
> document. We have identified certain normative changes and 
> deferred them to other documents, such as the reinvite draft.
> 
> I have certainly *tried* to draw the line so that if certain 
> points are not explicit in normative RFCs, that at least they 
> are corollaries that can be derived from the RFCs. In some 
> cases I think this has been stretched a bit further to proofs 
> by contradiction - where any other interpretation would lead 
> to non-functional behavior and so must not have been 
> intended. And then there are some places that really are BCP 
> material in that they are of the form: the bad things that 
> might happen won't if you behave in the following way.
> 
> In some sense it would be *easier* if this were a normative 
> document, in that we would no longer have to find all those 
> rationalizations. And maybe readers would prefer for it to be 
> normative because they then could justify following this 
> document without looking at the others for info on o/a. Yet, 
> even if we were to make it a normative document, I think 
> there would only be a *few* normative changes, and even those 
> I'm not intimately familiar with the rules and applicability 
> of BCPs. I gather if we went that way we can have normative 
> language that adds to or tightens that in standards track 
> RFCs, but can't do anything that loosens or contradicts such 
> documents. Is that right?
> 
> So I would like some guidance here. I think it makes sense to 
> at least move to BCP. But would it be better to do that, or 
> go standards track?
> 
> 	Thanks,
> 	Paul
> 
> > Minor Comments:
> > 
> > -- section 1.1: 
> > 
> > The need for normative language in a draft that states it 
> is not making any normative changes is telling.
> > 
> > -- section 2.2, 5th paragraph, last sentence: "The 488 
> response is another proposed solution, UAS may respond with a 
> 488 response and then UAC should send again a PRACK request 
> without an offer."
> > 
> > Please elaborate on "401 response cannot be avoided". 
> Perhaps something to the effect of "For example, the UAS may 
> need to send an authentication challenge in a 401 response."
> > 
> > --2.2, paragraph 9:
> > 
> > Are you certain there are no normative changes here? Can 
> all the assertions be supported unambiguously by existing specs? 
> > 
> > Does that make it a fake answer? I don't think "real" is 
> the property you are looking for. Perhaps " not a final 
> answer" or "preliminary answer" would be. Ore descriptive?
> > 
> > -- 3.1.1, paragraph before figure 1: "Therefore, a UAS 
> should send a SDP answer reliably (if possible) before it 
> starts sending media."
> > 
> > -- 3.1.2, last paragraph, last sentence: "The UAC should 
> take care to avoid this situation when it sends the INVITE 
> request without SDP."
> > 
> > How? Are you suggesting that you shouldn't send an empty 
> invite unless you can accept any answer without user intteraction?
> > 
> > Can you elaborate on "should not send...at this point"? For 
> example, should not send the reINVITE until...
> > 
> > -- 5.1, first paragraph: "...without regard for what the 
> other party in the call may have indicated previously."
> > 
> > This is not universally true. For example, the sender may 
> have access to the recipient's presence information, which it 
> generally shouldn't ignore.
> > 
> > 5.2.3, first paragraph: "The media lines that are accepted 
> should typically be those with types and formats the UAS 
> would have included if it were the offerer"
> > 
> > I'm not sure how to apply that advice to make any useful 
> decision. For example, if I might not have offered video, 
> should I reject a media stream in someone else's offer?
> > 
> > 
> > 
> > 
> > -- Please proofread for the following recurring errors: 
> comma-spliced run-on sentences, missing articles, and 
> incorrect selection of "a/an" vs "the".
> > 
> > I'm not sure what you mean by " carefully restricted in the 
> RFCs" Are you suggesting a change in existing or future RFCs?
> > 
> > I find it curious to ascribe wants and interests to the UA. 
> This leads to some awkward constructions when discussing how 
> a UA may not know what it wants. 
> > 
> > 
> > 
> > 
> > 
> > 
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 May 2010 09:12:44 -0400

Keith,

This document has been walking a fine line between clarification and 
normative change, trying to stay on the clarification side. Whether it 
has crossed the line is debatable. Do you have an opinion on that point 
- do you think we have strayed into normative changes, or are we still 
just clarifying what was always the intent?

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 24 May 2010 15:34:12 +0200

I believe it had not added anything beyond the scope you set, which is why I believe it can be informative.

If anyone believes we need anything stronger, then I believe we should revise the existing specifications, otherwise in this area, we merely add more confusion by multiple layers of specification.

regards

Keith

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, May 24, 2010 2:13 PM
> To: DRAGE, Keith (Keith)
> Cc: Ben Campbell; [email-masked]; [email-masked]
> This document has been walking a fine line between 
> clarification and normative change, trying to stay on the 
> clarification side. Whether it has crossed the line is 
> debatable. Do you have an opinion on that point
> - do you think we have strayed into normative changes, or are 
> we still just clarifying what was always the intent?
> 
> 	Thanks,
> 	Paul
> 
> > I have a distinct reluctance to go anywhere with this 
> document that has any implications of a normative nature.
> > 
> > Essentially if as a result of the analysis of this 
> document, we believe something needs fixing, then we should 
> go back and create bis versions of RFC 3264 or RFC 3262. This 
> is not an area where we need yet more add on specifications 
> to what is already the supposed normative documents in this area.
> > 
> > regards
> > 
> > Keith
> > 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >> Paul Kyzivat
> >> believe this needs to be standards track, or a BCP. For 
> that purpose, 
> >> I think it's on the right track, but I have some other 
> minor comments 
> >> and questions that I think should be addressed first.
> >>
> >> See below.
> >>
> convinced. 
> >> There are a number of places where it has the practical effect of  
> >> updating or adding normative constraints to existing proposed 
> >> standards. I think it would be best to make this standards or BCP 
> >> track and drop the pretense of being non-normative.
> >>
> >> When we first started working on this (five years ago) it was the 
> >> intent and expectation that this would be an informative 
> document. We 
> >> have identified certain normative changes and deferred 
> them to other 
> >> I have certainly *tried* to draw the line so that if 
> certain points 
> >> are not explicit in normative RFCs, that at least they are 
> >> corollaries that can be derived from the RFCs. In some 
> cases I think 
> >> this has been stretched a bit further to proofs by contradiction - 
> >> where any other interpretation would lead to 
> non-functional behavior 
> >> and so must not have been intended. And then there are some places 
> >> that really are BCP material in that they are of the form: the bad 
> >> things that might happen won't if you behave in the following way.
> >>
> >> In some sense it would be *easier* if this were a 
> normative document, 
> >> in that we would no longer have to find all those 
> rationalizations. 
> >> And maybe readers would prefer for it to be normative because they 
> >> then could justify following this document without looking at the 
> >> others for info on o/a. Yet, even if we were to make it a 
> normative 
> >> document, I think there would only be a *few* normative 
> changes, and 
> >> even those might be debated as not *really* being changes.
> >>
> >> I'm not intimately familiar with the rules and 
> applicability of BCPs. 
> >> I gather if we went that way we can have normative 
> language that adds 
> >> to or tightens that in standards track RFCs, but can't do anything 
> >> that loosens or contradicts such documents. Is that right?
> >>
> >> So I would like some guidance here. I think it makes sense to at 
> >> least move to BCP. But would it be better to do that, or 
> go standards 
> >> track?
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >>> Minor Comments:
> >>>
> >>> -- section 1.1: 
> >>>
> >> 488 response and then UAC should send again a PRACK 
> request without 
> >> an offer."
> >> Perhaps something to the effect of "For example, the UAS 
> may need to 
> >> send an authentication challenge in a 401 response."
> >>> --2.2, paragraph 9:
> >>>
> >> the property you are looking for. Perhaps " not a final answer" or 
> >> "preliminary answer" would be. Ore descriptive?
> >> should send a SDP answer reliably (if possible) before it starts 
> >> sending media."
> >> take care to avoid this situation when it sends the INVITE request 
> >> without SDP."
> >> decision. For example, if I might not have offered video, should I 
> >> reject a media stream in someone else's offer?
> >>>
> >>>
> >>>
> >> comma-spliced run-on sentences, missing articles, and incorrect 
> >> selection of "a/an" vs "the".
> >> This leads to some awkward constructions when discussing 
> how a UA may 
> >> not know what it wants.
> >>>
> >>>
> >>>
> >>>
> >>>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 24 May 2010 08:38:04 -0500

I guess my main concern is in the areas where the draft "interprets" 3261 et al with normative or near normative statements. If those interpretations can be unambiguously derived from the existing specs, then I have no problem with it being informational. 

But if it's just taking one possible interpretation out of many, and asserting that to be the correct one, then I think we're looking at BCP material.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 24 May 2010 09:57:34 -0500

As an individual, I would prefer to keep this as an informational document rather than trying to rework it as a proposed standard.

As AD, I need to push a little on BCP. I don't believe this kind of document is a BCP as that document status was intended to be used.
There are some slides that I used as part of a discussion on what BCPs are last summer at 
<http://www.nostrum.com/~rjsparks/bcp.pdf>. The important part is that the BCP series was not intended to be "more important
informational documents". This particular document should either be informational or PS.

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 May 2010 11:21:21 -0400

Ben, Robert,

How would you like to proceed here?
Do we need to search the document for all the "interpretations", and 
then discuss whether we have sufficient evidence for each as to whether 
it is the one and only valid interpretation?

Should we then set out a statement of such "corollaries" in such a way 
that we can cite them as we would cite the RFCs?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 May 2010 11:25:43 -0400

> informational documents". This particular document should either be informational or PS.

I looked through those slides, and I feel just as confused about BCPs as 
I did before.

The places where I think it seems to me like a BCP are those where it 
says, roughly: "you don't have to do things this way, but your life will 
be easier and the outcome may be better if you do." But I'm left not 
knowing if that ought to be justification for BCP.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 24 May 2010 10:48:41 -0500

> informational documents". This particular document should either be informational or PS.

Does it not "...standardize the results of community deliberations about...conclusions about what is the best	 way to perform some operations..."? To rehash some specific examples:

Section 3.1.1 offers an "interpretation" of the offer/answer language from 3261. This interpretation is stated with normative language. Do we believe that interpretation in unambiguous? That is, would any reasonable person skilled in the art come to the same interpretation? If not, then it seems to me we are creating new normative constraints over and above those of 3261. If "yes", on the other hand, then why do we need to clarify it?

Section 4.3 does a similar interpretation of spec, but this time is interpreting non-normative language, and itself avoids normative language. But I offer that it avoids normative language in form, but not in substance. I'm skeptical of the idea of stating a lower-case "must", where there seem to be some bad things that may happen if you don't follow it, for the purposes of avoiding the form of normative language.

I guess it really comes down to the practical question of how important is it for implementors to pay attention to this. Are there interop issues if one does and another does not?

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 24 May 2010 11:08:38 -0500

I'm replying to Paul's note, having also looked at Robert's slides on BCP 
(and remembering that I happened to see that dicussion in person)...

I'm assuming that informational statements might have some impact on new 
implementations, but am struggling to imagine development resources being 
allocated to change from one conformant behavior to another one, if the 
standardization level of the new behavior is "we thiink this is the best way 
to do it, but don't comment out the code you've already deployed"...

Am I misunderstanding what's under discussion? That happens.

Spencer

> Do we need to search the document for all the "interpretations", and then 
> discuss whether we have sufficient evidence for each as to whether it is 
> the one and only valid interpretation?
>
>> I guess my main concern is in the areas where the draft "interprets" 3261 
>> et al with normative or near normative statements. If those 
>> interpretations can be unambiguously derived from the existing specs, 
>> then I have no problem with it being informational. But if it's just 
>> taking one possible interpretation out of many, and asserting that to be 
>> the correct one, then I think we're looking at BCP material.
>>
>>> Essentially if as a result of the analysis of this document, we believe 
>>> something needs fixing, then we should go back and create bis versions 
>>> of RFC 3264 or RFC 3262. This is not an area where we need yet more add 
>>> on specifications to what is already the supposed normative documents in 
>>> this area.
>>>
>>> regards
>>>
>>> Keith
>>>
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
>>>> Paul Kyzivat
>>>> believe this needs to be standards track, or a BCP. For that purpose, I 
>>>> think it's on the right track, but I have some other minor comments and 
>>>> questions that I think should be addressed first.
>>>>
>>>> See below.
>>>>
>>>> correct in pointing out our current offer/answer rules are scattered 
>>>> all over the place.
>>>>> Major Comments:
>>>>>
>>>>>
>>>> lengths to pretend to make no normative changes. I am not convinced. 
>>>> standards. I think it would be best to make this standards or BCP track 
>>>> and drop the pretense of being non-normative.
>>>>
>>>> intent and expectation that this would be an informative document. We 
>>>> have identified certain normative changes and deferred them to other 
>>>> In some sense it would be *easier* if this were a normative document, 
>>>> in that we would no longer have to find all those rationalizations. And 
>>>> response is another proposed solution, UAS may respond with a 488 
>>>> response and then UAC should send again a PRACK request without an 
>>>> offer."
>>>> Perhaps something to the effect of "For example, the UAS may need to 
>>>> have access to the recipient's presence information, which it generally 
>>>> shouldn't ignore.
>>>> should typically be those with types and formats the UAS would have 
>>>> included if it were the offerer"
>>>> This leads to some awkward constructions when discussing how a UA may 
>>>> not know what it wants.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 24 May 2010 11:11:46 -0500

Still reading ...

> Section 4.3 does a similar interpretation of spec, but this time is 
> interpreting non-normative language, and itself avoids normative language. 
> But I offer that it avoids normative language in form, but not in 
> substance. I'm skeptical of the idea of stating a lower-case "must", where 
> there seem to be some bad things that may happen if you don't follow it, 
> for the purposes of avoiding the form of normative language.

Yes, this worries me. I'm agreeing with Ben here.

> I guess it really comes down to the practical question of how important is 
> it for implementors to pay attention to this. Are there interop issues if 
> one does and another does not?

I agree this is the key question.

Thanks,

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 May 2010 13:22:51 -0400

Spencer Dawkins wrote:
> I'm replying to Paul's note, having also looked at Robert's slides on 
> BCP (and remembering that I happened to see that dicussion in person)...
> 
> implementations, but am struggling to imagine development resources 
> being allocated to change from one conformant behavior to another one, 
> if the standardization level of the new behavior is "we thiink this is 
> the best way to do it, but don't comment out the code you've already 
> deployed"...

Its a little more than that.

The typical situation is, I think, that implementations are working for 
the cases they have encountered, and probably for some others. But many 
will not work correctly for some cases that may come up rarely if at all 
in current deployments. Those are latent problems waiting to happen as 
new interop cases are tried and new features are added.

So, if you did your implementation without considering the stuff in this 
draft, you can wait till you have a problem, or you can review your 
implementation to see if it handles all these cases.

	Thanks,
	Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 24 May 2010 12:28:08 -0500

Hi, Paul,

>> standardization level of the new behavior is "we thiink this is the best 
>> way to do it, but don't comment out the code you've already deployed"...
>
> in current deployments. Those are latent problems waiting to happen as new 
> interop cases are tried and new features are added.
>

Thanks, that was helpful.

Spencer

---

From: Robert Sparks <[email-masked]>
Date: Mon, 24 May 2010 17:46:55 -0400

> Does it not "...standardize the results of community deliberations about...conclusions about what is the best	 way to perform some operations..."? To rehash some specific examples:

That quote is talking about operations of the IETF or bodies like IANA, not about the operations of protocols. There is also a hook for talking about
full-and-immediate implementation of something like the configuration or some other operational aspect of a system like the global DNS.

> I guess it really comes down to the practical question of how important is it for implementors to pay attention to this. Are there interop issues if one does and another does not?

If so, I believe you are making an argument for PS, not BCP.

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 25 May 2010 12:48:15 +0900

Hello my master,

Ben Campbell <[email-masked]>
Mon, 24 May 2010 10:48:41 -0500
>Does it not "...standardize the results of community deliberations about...conclusions about what is the best	 way to perform 
>some operations..."? To rehash some specific examples:
>
>Section 3.1.1 offers an "interpretation" of the offer/answer language from 3261. This interpretation is stated with normative 
>language. Do we believe that interpretation in unambiguous? That is, would any reasonable person skilled in the art come to 
>the same interpretation? If not, then it seems to me we are creating new normative constraints over and above those of 3261. 
>If "yes", on the other hand, then why do we need to clarify it?
>
>Section 4.3 does a similar interpretation of spec, but this time is interpreting non-normative language, and itself avoids 
>normative language. But I offer that it avoids normative language in form, but not in substance. I'm skeptical of the idea of 
>stating a lower-case "must", where there seem to be some bad things that may happen if you don't follow it, for the purposes 
>of avoiding the form of normative language.

The lower-case "must" means that it is based on normative
specifications but the specifications is defined in another
text.
At least I intended so.

Regards,
Shinji

>I guess it really comes down to the practical question of how important is it for implementors to pay attention to this. Are 
>there interop issues if one does and another does not?
>
>
>> RjS
>> 
>>> This draft claims an intended status of "informational". I believe this needs to be standards track, or a BCP. For that 
>>> purpose, I think it's on the right track, but I have some other minor comments and questions that I think should be 
>>> addressed first.
>>> 
>>> -- The draft is listed as informational, and goes to great lengths to pretend to make no normative changes. I am not 
>>> convinced. There are a number of places where it has the practical effect of  updating or adding normative constraints to 
>>> existing proposed standards. I think it would be best to make this standards or BCP track and drop the pretense of being 
>>> non-normative.
>>> 
>>> 
>>> Minor Comments:
>>> 
>>> -- section 1.1: 
>>> 
>>> -- section 2.2, 5th paragraph, last sentence: "The 488 response is another proposed solution, UAS may respond with a 488 
>>> response and then UAC should send again a PRACK request without an offer."
>>> 
>>> Please elaborate on "401 response cannot be avoided". Perhaps something to the effect of "For example, the UAS may need to 
>>> Does that make it a fake answer? I don't think "real" is the property you are looking for. Perhaps " not a final answer" or 
>>> I'm not sure how to apply that advice to make any useful decision. For example, if I might not have offered video, should I

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 May 2010 20:59:10 +0200

Hi,

If the "must" refer to normative statements in other specification, I think it would be good to add a reference to that specification.

"As described in RFC XXXX, the UA must do this and that..."

...or something like that.

If I remember correctly, one purpose of the draft was also to identify changes that might have to be done in other specifications (for example, reject offer in PRACK).

So, depending on how many "clarifications" the draft contains, and especially if they seem to become more of a normative statement nature, one possible outcome could be: update RFC3264.

No, I didn't say we should do it, but in my opinion it IS a possible outcome that should be taken into consideration.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of OKUMURA Shinji
Sent: 25. toukokuuta 2010 6:48
To: Ben Campbell; Robert Sparks
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [RAI] RAI-ART review of draft-ietf-sipping-sip-offeranswer-13

Hello my master,

>> As an individual, I would prefer to keep this as an informational 
>> document rather than trying to rework it as a proposed standard.
>> 
>> As AD, I need to push a little on BCP. I don't believe this kind of 
>> document is a BCP as that document status was intended to be used.
>> There are some slides that I used as part of a discussion on what 
>> BCPs are last summer at <http://www.nostrum.com/~rjsparks/bcp.pdf>. 
>> The important part is that the BCP series was not intended to be "more important informational documents". This particular document should either be informational or PS.
>> 
>
>Section 3.1.1 offers an "interpretation" of the offer/answer language 
>from 3261. This interpretation is stated with normative language. Do we 
>believe that interpretation in unambiguous? That is, would any reasonable person skilled in the art come to the same interpretation? If not, then it seems to me we are creating new normative constraints over and above those of 3261.
>interpreting non-normative language, and itself avoids normative 
>language. But I offer that it avoids normative language in form, but 
>not in substance. I'm skeptical of the idea of stating a lower-case "must", where there seem to be some bad things that may happen if you don't follow it, for the purposes of avoiding the form of normative language.

The lower-case "must" means that it is based on normative specifications but the specifications is defined in another text.
At least I intended so.

Regards,
Shinji

>I guess it really comes down to the practical question of how important 
>is it for implementors to pay attention to this. Are there interop issues if one does and another does not?
>
>
>> RjS
>> 
>>> This draft claims an intended status of "informational". I believe 
>>> this needs to be standards track, or a BCP. For that purpose, I 
>>> think it's on the right track, but I have some other minor comments and questions that I think should be addressed first.
>>> 
>>> And BTW, I think this is a great document to have, as it is correct 
>>> in pointing out our current offer/answer rules are scattered all over the place.
>>> 
>>> Major Comments:
>>> 
>>> 
>>> -- The draft is listed as informational, and goes to great lengths 
>>> to pretend to make no normative changes. I am not convinced. There 
>>> are a number of places where it has the practical effect of  
>>> updating or adding normative constraints to existing proposed standards. I think it would be best to make this standards or BCP track and drop the pretense of being non-normative.
>>> 
>>> 
>>> Minor Comments:
>>> 
>>> -- section 1.1: 
>>> 
>>> -- section 2.2, 5th paragraph, last sentence: "The 488 response is 
>>> another proposed solution, UAS may respond with a 488 response and then UAC should send again a PRACK request without an offer."
>>> 
>>> Please elaborate on "401 response cannot be avoided". Perhaps 
>>> something to the effect of "For example, the UAS may need to send an authentication challenge in a 401 response."
>>> 
>>> --2.2, paragraph 9:
>>> 
>>> Does that make it a fake answer? I don't think "real" is the 
>>> property you are looking for. Perhaps " not a final answer" or "preliminary answer" would be. Ore descriptive?
>>> 
>>> -- 3.1.1, paragraph before figure 1: "Therefore, a UAS should send a 
>>> SDP answer reliably (if possible) before it starts sending media."
>>> 
>>> -- 3.1.2, last paragraph, last sentence: "The UAC should take care 
>>> to avoid this situation when it sends the INVITE request without SDP."
>>> 
>>> This is not universally true. For example, the sender may have 
>>> access to the recipient's presence information, which it generally shouldn't ignore.
>>> 
>>> 5.2.3, first paragraph: "The media lines that are accepted should 
>>> typically be those with types and formats the UAS would have included if it were the offerer"
>>> 
>>> I'm not sure how to apply that advice to make any useful decision. 
>>> For example, if I might not have offered video, should I reject a media stream in someone else's offer?
>>> 
>>> 
>>> 
>>> 
>>> comma-spliced run-on sentences, missing articles, and incorrect selection of "a/an" vs "the".
>>> 
>>> I find it curious to ascribe wants and interests to the UA. This 
>>> leads to some awkward constructions when discussing how a UA may not know what it wants.
>>> 
>>> 
>>> 
>>> 
>>> 
>>