Subject: Re: [Sip] WGLC for draft-ietf-sip-answermode-00

From: Dean Willis <[email-masked]>
Date: Tue, 25 Apr 2006 23:29:57 -0500

Thank you, Hans, for the incredibly detailed recounting of my  
horrific typographical error-rate. I have worked through your list  
point-by-point. Comments follow.

On Feb 23, 2006, at 6:37 AM, Hans Persson wrote:

> tor 2006-02-23 klockan 04.32 skrev Rohan Mahy:
>
>> I'd like to start a 3-week working group last call for:
>>
>> 	draft-ietf-sip-answermode-00.txt
>
> I have a couple of questions where I would like clarifications and a
> whole slew of nits.
>
>
> Questions:
>
> Page 8, Req-11: I'm not able to make sense of "[...] knowledge that  
> may
> be important in informing UAC-user's usage of the session.".

I've revised this to say:

This knowledge may be important to UAC-user's decision-making process  
about how to use the session. For example, UAC-user may wish to ask  
"Are you there?" if the request was answered automatically.

>
> Page 12, Section 4.2.1: In this paragraph is the text: "must be done
> very carefully and only in the context of an external agreement  
> between
> the proxy operator and the user of the UA.". The text "the UA"
> (singular) implies that we're talking about only one of the UAC and  
> the
> UAS and not both, but I think it would be good to explicitly state  
> which
> one is meant (I assume it would be the UAS, but more clarity won't
> hurt).
>

Changed to:

only in the context of an external agreement between the proxy  
operator and the user of the UA that the proxy is serving.

>
> Nits:
>
> Page 5, last paragraph: intercom(m) is spelled with first one, then  
> two,
> then again one "m".
>

happens when you mix a Brit and a Texan on one draft. I've changed to  
"intercom" globally.

> Page 6, first (complete) paragraph: two instances of "caes" instead of
> "cases" and one of "Ther" instead of "There".

Fixed.

> Req-1: "for UAC" should be "for the UAC" and "UAS-user" should be "the
> UAS-user".
>

Ah, the joyous subtleties of English.

In this context, UAC and UAS-User are serving as proper or  
"placeholder" nouns (based on the definitions in 2).

So here, we're speaking of UAC as a specific reference instance of "a  
UAC" within the reference model of this draft.

One would not say "for the Alice". Instead, one would say "for Alice".

It may be that this style, although correct, just doesn't work for  
non-native readers of English. If that's so, then I'll rewrite the  
whole section.

It also means that there's an extra "the" in Req-2 that is not  
consistent. My bad.

I've added the following just before the requirements:
     <figure anchor='uac-uas'>
         <preamble>The relationship between the entities used in  
these requirements is shown in the following:</preamble>
         <artwork>

       UAC-User           UAC             UAS          UAS-USer
           |               |               |               |
           |               |               |               |
           |               |               |               |
           |(1) Uses       |               |               |
           |-------------->|               |               |
           |               |               |(2) Uses       |
           |               |               |<--------------|
           |               |(3) REQUEST    |               |
           |               |-------------->|               |
           |               |(4) RESPONSE   |               |
           |               |<--------------|               |
           |               |               |               |
           |               |               |               |

         </artwork>
         <postamble>Note that "UAC-User", "UAC", "UAS", and "UAS- 
User" are referenced as actors in the following discussion."</postamble>
     </figure>

> Page 7, Req-2: "the UAC", "the UAS-user", "the UAS".
> Req-3: "the UAS".
> Req-4: "the UAC", "the UAS". Period missing at the end.

Fixed missing period.

> Req-5: "the UAC"
> Req-6: "the UAS" (twice), "and or" should be "and/or".

fixed and/or

> Req-7: "the UAS", duplicated "that", "the UAS".
>

fixed duplicated "that"

> Page 8, Req-9: "the UAC", "the UAS".
> Req-10: "the UAC or the UAS"
> Req-11: "the UAS", "the UAC", "the UAC-user".
>

> Req-12: "a UAS" or "UASs". Actually this type of form may be the  
> correct
> choise for some of the above cases as well, but *something* is
> definitely missing.
>

Yes, that was clumsy. I rephrased this as:

It MUST be possible for UAS to maintain the privacy expectations of  
UAS-User. According to local policy, UAS MAY either 1) not include  
information about which answering mode was applied in a response or  
2) include misleading information about which answering mode was  
applied. Consequently, applications MUST NOT rely on the veracity of  
this information in the response.

> Page 9, last paragraph of section 3: shouldn't this be  
> "implementations
> MUST" for clarity?

Good question. Typically implementations just ignore unknown stuff --  
this isn't a MUST of this specification, it's just the way SIP works.  
However, here we have a specific goal in mind, so I've rephrased the  
paragraph substantially in order to support a MUST:

Note also that this syntax includes extension hooks, "generic-param"  
for parameters, and "token" for options, that may be defined in  
future specifications extending this one. This specification defines  
only the behavior for the values given explicitly above. In order to  
provide forward compatibility, implementations MUST ignore unknown  
values.

> Last paragraph: Period missing before "For example".

Fixed.

>
> Page 10, first paragraph of section 4.1.3: insert "an" before
> "appropriate parameter".

Arguable, but I've added an "an" as requested.

> second paragraph, 4.1.3: "a Answer-Mode" should be "an Answer-Mode".
> Ditto in the following three paragraphs.
>

fixed.

> Page 11, third (complete) paragraph: It looks messy to put text
> containing double quotes inside double quotes. The same goes for the
> following two paragraphs. In the last of these three, the problematic
> passage also contains an extra spurious double quote.
>

Ok, I've added lots of figures showing the syntax that might have  
been obfuscated by quotes, and deleted the spurious doubleqoute.

Example:

    To request that retargeting proxies in the path preferentially  
select
    targets that have indicated support for this extension in their
    registration, a UAC includes an Accept-Contact header field having a
    parameter of "extension="answermode"".  This usage of Accept-Contact
    is described in [8].  Note that this would normally be used in
    conjunction with the "Require: answermode" header field as described
    above.

        Require: answermode
        Accept-Contact: *;extension="answermode";methods="INVITE"

> Page 12, first (incomplete) paragraph: "prefxing" should be  
> "prefixing".

fixed

> Section 4.2.1: "a Answer-Mode" should be "an...".

changed globally, even though some English books say we're referring  
to "a header", not "an Answer-Mode".

> Section 4.2.2, first paragraph: "UAS" -> "UASs" (twice, and once  
> each in
> the next two paragraphs).

It's doubtful as to whether pluralization of an acronym ending in S  
requires adding another S. It might do to add an "es", as in UASes.  
Or one can treat them as self-plurals, which is what I did.

> Page 13, section 4.3.1, first paragraph: "for unattended UAS" -> "for
> unattended UASs".
> Third paragraph: "a Answer-Mode" -> "an ...".
> Fourth paragraph: This talks about 'an Answer-Mode *parameter* of
> "Auto"'. The previous paragraph has 'an Answer-Mode *value* of  
> "Auto"'.
> Please use a consistent naming scheme.

Here's the rub: When we're talking about a modifier for a header  
field, we're talking about a parameter. When we talk about a specific  
setting for that parameter (assuming that the parameter supports  
such), we're talking about "parameter values", usually shortened to  
"values".

So we're really talking about the value of an Answer-Mode parameter  
in both of the above cases.

I don't know why we try to write specs in English. It's too damned  
subtle.

Anyhow, I've polished the usage throughout the document. Maybe it's  
better.

>
> Page 15, section 5, first paragraph: Duplicated "the".
>

fixed.

> Section 5.1: "a Answer-Mode" -> "an..." (twice).
>
> Page 16, first (incomplete) paragraph: "UAS" (last instance) ->  
> "UASs".
> Section 6: Duplicated "an". "asnwering" -> "answering".
>

fixed.

> Page 19, first (incomplete) paragraph: Duplicated "a".

fixed.

>
> Page 20, first item 1: Missing period at end.

fixed.

> Item 4: "nee o" -> "need to".

fixed.

> First paragraph after items 1-5: Extra comma before "[2]".
>

Fixed.

> Second item 1: Missing period at end (and also for item 2, on the next
> page).

Fixed.

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Tue, 25 Apr 2006 23:41:27 -0500

Thanks! I've applied these suggestions in the revised draft.
--
Dean

On Feb 23, 2006, at 12:09 PM, Jeroen van Bemmel wrote:

> Rohan,
>
> Two remarks:
> 1. I would propose to change the ABNF to allow for a list of  
> generic-params, as is common for most SIP headers
>    The current version limits the extensibility to 1 parameter  
> (name=value) which would replace "Manual" or "Auto", and possibly a  
> list of tokens (which would be interpreted as flag parameters)
>
> How about the following:
> Answer-Mode = "Answer-Mode" HCOLON answer-mode *(SEMI answer-mode- 
> param)
> Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode *(SEMI  
> answer-mode-param)
>
> answer-mode = "Manual" / "Auto" / token
> answer-mode-param = "require" / generic-param2. (NIT) Example  
> section 6.2, "Requires" header should be "Require"
>
> Regards,
>
> jeroen
>
>
> ----- Original Message ----- From: "Rohan Mahy" <[email-masked]>
> To: "SIP WG" <[email-masked]>
> Cc: "Dean Willis" <[email-masked]>
> Sent: Thursday, February 23, 2006 4:32 AM
> Subject: [Sip] WGLC for draft-ietf-sip-answermode-00
>
>
>> Hi,
>>
>> This WGLC will complete on March 15th
>>
>> thanks,
>> -rohan
>>
>> Rohan Mahy
>> co-chair SIP WG
>>
>>

---

From: Dean Willis <[email-masked]>
Date: Tue, 25 Apr 2006 23:51:55 -0500

I've addressed the typos.

On Feb 24, 2006, at 12:16 AM, Paul Kyzivat wrote:

> OK, I reviewed this one more time. Below are a bunch of things.  
> They are all small except for the last one.
>
> 	Paul
>
> Rohan Mahy wrote:
>> Hi,
> There are several instances of a feature tag of  
> "extension="answermode"". That ought to be "extensions".
>
> (I know dean consulted me on this long ago to get it right, so its  
> most likely my own error.)
>
> Note that there are also some correct usages in the doc.
>
> In section 6.1, a Contact header is folded across multiple lines,  
> but the subsequent lines are not indented.
>
> In section 7.3: s/nee o make/need to make/
>
> In section 7.4:
>
>    User agents implementing this specification MUST NOT establish a
>    session providing outbound or bidirectional media without explicit
>    user acceptance.
>
> Isn't this a little strong? It totally eliminates the baby monitor  
> as a supported application. It also eliminates using this in  
> support of a loopback test mode.
>

I've rephrased this final bit as:

User agents implementing this specification MUST NOT establish a  
session providing outbound or bidirectional media sourced from the  
user agent without explicit user acceptance. Note that "loopback"  
media used for connectivity testing is not constrained by this  
requirement. This requirement is intended to assure that this  
extension can not be used to turn a UAS into a remote-controlled  
microphone (or "bug") without the knowledge of its user.

--
Dean