[Sip] Re: Comments on draft-ietf-sip-location-conveyance-03

["James M. Polk" <[e-mail]>]

At 11:51 PM 7/3/2006 +0100, Drage, Keith (Keith) wrote:
Keith

in-line

>I have the following comments on the above draft:
>
>Structural
>----------
>
>1)      Abstract: From reading the document, it is clear that presence 
>systems are not covered at all in this document for various reasons. 
>Therefore PUBLISH, SUBSCRIBE and NOTIFY are essentially out of scope. It 
>seems to me that this should be made much more explicit in the abstract.

The first line of the abstact states:

"This document defines how the Session Initiation Protocol (SIP) conveys, 
or pushes, geographic location information from one SIP entity to another 
SIP entity."

Since SUB/NOT is not a "push" form of transaction, I believe this satisfies 
what you are looking for.  I admit I do not call out each of the 14 Methods 
that this extension does affect, but I rarely see this done in any SIP 
document, so I didn't know it was necessary here. For example RFC 4538 
doesn't say in the abstract it is only used in INVITE, SUB and NOT, and not 
all the others.

Section 4 clearly states that this extension can be used in SUB and NOT, 
but this is out of scope for this document because they are pull based 
transactions.  Section 4 also states that PUB is out of scope.


>2)      The SIP extension guidelines (RFC 4485) need to be applied to this 
>document, which requires some substantial restructuring.

I believe this will only result in section 4 and 5 being modified, and not 
any other section (structurally - unless the reqs are moved to an appendix)

>The absence of application of these rules mean that the requirements of 
>the document are extremely unclear. For example RFC 4485 states (section 4.5):
>
>    Developers of protocols often get caught up in syntax issues, without
>    spending enough time on semantics.  The semantics of a protocol are
>    far more important.  SIP extensions MUST clearly define the semantics
>    of the extensions.  Specifically, the extension MUST specify the
>    behaviors expected of a UAC, UAS, and proxy in processing the
>    extension.  This is often best described by having separate sections
>    for each of these three elements.  Each section SHOULD step through
>    the processing rules in temporal order of the most common messaging
>    scenario.
>
>Absence of this application means that in places in this document it is 
>impossible to determine whether a requirement and its required support 
>occurs as the sender of the location information, or the receiver of the 
>location information.

This document is written almost exclusively as a UAC pov extension, since 
it, by definition, is what is "conveying" location.  Thus, little about 
this document is about a UAS, save a line that discusses that element can 
response with location.

A little bit more of this doc discusses what a proxy does with this 
extension, with most of the original material from past version removed, to 
be put into ECRIT documents.

I will make element operation wrt this extension much more explicit in the 
next rev.


>3)      Section 1 (and possibly section 2) should be redrafted taking into 
>account RFC 4485 section 4.7:
>
>    Too often, extension documents dive into detailed syntax and
>    semantics without giving a general overview of operation.  This makes
>    understanding of the extension harder.  It is RECOMMENDED that
>    extensions have a protocol overview section that discusses the basic
>    operation of the extension.  Basic operation usually consists of the
>    message flow, in temporal order, for the most common case covered by
>    the extension.

This document, per a conversation between you, me and Dean, in Dallas, is 
to include the requirements for this extension in the front of the 
document, and not deleted or put in an appendix.  This is due to this 
document origin as a SIPPING Requirements document.  This means I have to 
get to the requirements section, which is section 3.  This means I cannot 
get into the classic "Basic Operation" until the section after that - 
Section 4.  Section 4 states it is a Basic Operation section at the top of 
the third paragraph, followed by the two basic message flows (Figure 1 and 
2).  Perhaps I should have called the section "Basic Operation of SIP 
Location Conveyance" instead of "Location Conveyance Using SIP". I will fix 
this in the next rev.  But section 4 is what you are looking for per RFC 
4485 section 4.7.

>The most important processing rules for the elements
>    in the call flow SHOULD be mentioned.

they are

>Usage of the RFC 2119 [1]
>    terminology in the overview section is NOT RECOMMENDED, and the
>    specification should explicitly state that the overview is tutorial
>    in nature only.

I do need to work on this.  This will be addressed in the next rev.  There 
is a good segway in section 4 right now, I just didn't divide that point 
into a new section - but I will now.

>This section SHOULD expand all acronyms, even those
>    common in SIP systems, and SHOULD be understandable to readers who
>    are not SIP experts.

I believe it does

>[27] provides additional guidance on writing
>    good overview sections.
>
>I found this text much too wordy, and considered that it should be 
>possibly to convey the necessary information to the reader in about half 
>the length.

"this text" meaning exactly what text? Section 1, Section 2 or both?  I 
think section 1 is discussing scenarios that offer unique ideas about 
location conveyance, and what is going into which section.  Section 2 has 
more words than it probably should.


>4)      Section 3 need to have all the RFC 2119 language removed (see 
>history-info and outbound as examples).

Section 3 is only requirements, and you said in Dallas they stay where they 
are because this ID stated as a Reqs only doc in SIPPING, so I'm confused 
as to which you want.

>I remain open as to whether it appears at the start of the document, as 
>here and in history-info, or at the end, as in outbound, but given the 
>length, we may want to consider moving it to the end.

Again, this is where you said to keep them (in Dallas), so I did.  Are you 
changing your mind?  If so, given that you hadn't told me prior to after 
the document deadline, I'm not surprised I didn't do it another way.  That 
said, I can move the reqs to an appendix, and mention this is where they 
are in section 1.


>5)      Section 6 should probably follow immediately on from the 
>procedures in the bulk of section 4, and probably be split as in comment 
>2) above.

Based on what you said above, I agree that section 4 and 5 will be modified.


>6)      Section 7 should be integrated into the main procedures text.

hmm... I think calling out how this SIP extension complies with RFC 3693 in 
its own section is appropriate (readers can see this glaring at them in the 
TOC), but it doesn't make sense until the extension is explained, which 
would be hard to undertand before section 5.


>Technical
>---------
>
>7)      Section 1, of the three examples given in this introduction, item 
>2) is out of scope. I had to read an awful lot of text to discover that fact.

I disagree. Think of the REGISTER request, in which a Registrar responds 
with different information based on where the UAC is.

I have a couple of IDs in another WG that take this usage and run with it:
http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-server-uri-00.txt
http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency-dialstring-00.txt
http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-during-registration-00.txt


>8)      Section 2, 1st paragraph. Probably not appropriate to use the term 
>"trust model". That term is defined in RFC 3324 and RFC 3325, and I am not 
>convinced the usage here is one and the same.

Should I use "e2e trust" vs. non-e2e trust"?

3325 talks about the UAS trusting the Proxy to assert the PAI is accurate 
about the UAC.

Here, this is from the UAC's pov, and making a decision based on where it 
believes the information will be used (only at the destination UAS, or by a 
proxy to use for message routing based on where the UAC is).  This seems 
like a model; either e2e or used by an intermediary to get the message to 
the right endpoint.

Any suggestions?


>9)      Section 2, 3rd para.
>
>    No routing of the request based on the location contents is required
>    in this case, therefore no SIP Proxies between these two UAs need to
>    view the location information contained in the SIP message(s).  The
>    UAC should know certain types of messages will be routed based on
>    the UA's location when creating a message.
>
>Did not understand what this paragraph is meant to be telling me - can you 
>explain it.

yes

In the previous paragraphs it was concluded by the UAC no help was needed 
in the network, from a location conveyance pov, to find the destination 
UAS, therefore merely sending location in the message body was enough.  The 
forth paragraph continues this train of thought stating RFC 3261 does not 
allow message bodies to be modified or deleted, and if a UAC wants location 
to be conveyed confidentially, it needs to employ an encryption mechanism 
(S/MIME).  Paragraphs 2, 3 and 4 could be a single, larger paragraph - but 
I broke it up.  Perhaps that was a mistake.


>10)     Section 3.1 UAC-4: This is not a generic requirement as it is 
>already identified that certain methods are outside the scope of this document.

This allows Location to be included in other SIP Requests (than those 
listed above this requirement).  Without this requirement, table 2 and 3 
would be pretty empty (with only INVITE dialog related requests with an 
'o', and everything else having a '-', meaning not allowed, and the doc 
states that 'some other Request MAY include location, but the authors do 
not see a reason for this at this time'.


>11)     Section 3.1 UAC-9, UAC-10: I assume this is specified this way so 
>that misconfiguration releases the location rather than hides it.

that's what UAC-9 is for, also if the first INVITE hid location, but a 
subsequent message (after recieving a 424) doesn't want to hide it to make 
sure this isn't the reason the message didn't get through.

UAC-10 allows for a user to "not" include location during an emergency 
call.  We already know of places that have this law on the books.

>I believe this contravenes the regulatory requirements of some countries.

Yes, and in those jurisdictions, that's an configuration issue, not a 
protocol issue.  My mobile phone needs to be able to roam between a 
jurisdiction that has such a law, and one that doesn't.

>I believe in Japan privacy requirements are more important that the 
>transmission of the information for emergency calls. If someone from Japan 
>was writing these requirements they would therefore indicate exactly the 
>opposite.

Again, this is an configuration issue.  There are places where the user has 
no choice in the matter, other places the user has a choice.


>12)     Section 3.2 UAS-6 and section 3.3 Proxy-4. Firstly this is halfway 
>into implementation. Secondly if it is required to address location errors 
>in requests, why is the same consideration not given to location errors in 
>responses.

Are you asking if there is an error in a SIP response?  How do you address 
that anytime?

Basically, I'm not understanding your question/comment 12. Can you rephrase?


>13)     Section 3.3 Proxy-1: This merely repeats RFC 3261, rather than 
>developing a new requirement.

Fair - it does. I guess this was to remind readers of this.  It should be 
removed.


>14)     Section 3.3 Proxy-3: This seems to be rewriting the requirements 
>to correspond to the solution.

I disagree.  We have a problem in that there is no indicator of who 
generated a PIDF-LO (by-value or by-reference).  This is very real.  This 
requirement is stating that if there already is location in a message, not 
to add to the confusion factor if you can help it.

>I understand the problem is that the solution cannot distinguish between 
>multiple locations, nor understand the reliability, and therefore a 
>receiver may get confused. Firstly this does not seem to me to be a SIP 
>issue, and secondly in general the ability to transport multiple locations 
>could be regarded as useful - they just need some form of assertion as to 
>who provided which location.

but there is no form of assertion now... so what do we do, ignore the 
problem as it is today?


>15)     Section 4 and elsewhere. I don't find location in responses well 
>described at all.

I state that " Bob MAY choose to include his location in a response back to 
Alice."  Otherwise, I don't get into this other than it must obey the 
PIDF-LO format and privacy mechanisms of a request.

>It seems to be an afterthought, rather than something that is decided 
>based on a full set of requirements. I have already made a comment with 
>regard to requirements on error handling. Should we support location in 
>response, or force the UAS to generate a request of its own in order to 
>send a location?

fair question - I'm guess I'm ok with saying Location Conveyance is only in 
requests, but I didn't see the harm in Location being in a 200 OK to a 
request that had location in it.  Guidance/opinions welcome


>16)     Section 4. Should the instances of "URI" here be "URN".

I take URNs to be services (like urn:services:sos), and URIs to be records 
on a remote node to be accessed.  Based on that, I think locations are 
URIs, of which, a URL is a subset.


>17)     Section 4 specifies:
>
>    Because a person's location is generally considered to be sensitive
>    in nature, certain security measures need to be taken into account
>    when transmitting such information.  Section 26 of [RFC3261] defines
>    the security functionality SIPS for transporting SIP messages with
>    either TLS or IPSec, and S/MIME for encrypting message bodies from
>    SIP intermediaries that would otherwise have access to reading the
>    clear-text bodies.  SIP endpoints SHOULD implement S/MIME to encrypt
>    the PIDF-LO message body (part) end-to-end.  The SIPS-URI from
>    [RFC3261] MUST be implemented for message protection (message
>    integrity and confidentiality) and SHOULD be used when S/MIME is not
>    used.
>
>    The entities sending and receiving location MUST obey the privacy
>    and security rules in the PIDF-LO, regarding retransmission and
>    retention, to be compliant with this specification.
>
>    Self-signed certificates SHOULD NOT be used for protecting PIDF-LO,
>    as the sender does not have a secure identity of the recipient.
>
>However RFC 4119 is already normatively referenced which contains the 
>following text:
>
>    For the purposes of this document, only the securing of a PIDF
>    document as a whole, rather than element-by-element security, is
>    considered.  None of the requirements [10] suggest that only part of
>    the information in a location object might need to be protected while
>    other parts are unprotected; virtually any such configuration would
>    introduce potentials for privacy leakage.  Consequently, the use of
>    MIME-level security is appropriate.
>
>    S/MIME [5] allows security properties (including confidentiality,
>    integrity, and authentication properties) to be applied to the
>    contents of a MIME body.  Therefore, all PIDF implementations that
>    support the XML Schema extensions for location information described
>    in this document MUST support S/MIME; in particular, they MUST
>    support the CMS [6] EnvelopedData and SignedData content types, which
>    are used for encryption and digital signatures, respectively.  It is
>    believed that this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3,
>    and 14.4.
>
>    Additionally, all compliant applications MUST implement the AES
>    encryption algorithm for S/MIME, as specified in [8] (and per REQ
>    15.1).  Of course, implementations MUST also support the baseline
>    encryption and digital signature algorithms described in the S/MIME
>    specification.
>
>    S/MIME generally entails the use of X.509 [9] certificates.  In order
>    to encrypt a request for a particular destination end-to-end (i.e.,
>    to a Location Recipient), the Location Generator must possess
>    credentials (typically an X.509 certificate) that have been issued to
>    the Location Recipient.  Implementations of this specification SHOULD
>    support X.509 certificates for S/MIME, and MUST support password-
>    based CMS encryption (see [6]).  Any symmetric keying systems SHOULD
>    derive high-entropy content encoding keys (CEKs).  When X.509
>    certificates are used to sign PIDF Location Objects, the
>    subjectAltName of the certificate SHOULD use the "pres" URI scheme.
>
>Which set of text takes precedence?

I don't see the conflict.  Can you point any such conflict out?

Is it the SHOULD vs. MUST implement S/MIME?  If so, I'll change this ID 
back to MUST implement.


>18)     Section 4:
>
>    More than one location representation or format MAY be included in
>    the same message body part, but all MUST point at the same position
>    on the earth (altitude not withstanding), as this would confuse the
>    recipient by pointing at more than one position within the same
>    message body part.  There MAY be a case in which part or parts of
>    one location format and part or parts of another format exist in the
>    same message body part.  These complementary pieces of information
>    MUST point at the same position on the earth, yet are incomplete
>    within their own format. For example, there maybe be a latitude and
>    longitude in coordinate format and a civic altitude value to
>    complete a 3-dimensional position of a thing (i.e. which floor of a
>    building the UA is on in a building at a particular lat/long
>    coordinates pair).
>
>Not sure what "altitude not withstanding" means, particular as this is a 
>RFC 2119 MUST sentence.

It means with or without, it makes no difference.  There are 4000 datums. 
Some in 2D, and others in 3D.  WGS84 has both.  There is a movement in 
Geopriv to have coordinate format location only provide 2D and a civic 
format provide altitude within the same <location-info> element of the 
PIDF-LO.  This statement is regarding during times where civic is not 
supported, or a altitude is not available, consider the 2D location to be 
enough information to present location by.


>Additionally, the paragraph repeats the essence of the "same position on 
>the earth" in two separate MUST statements.

I'll work on that, I was attempting to cover a separate angle of the same 
meaning.


>19)     Section 4:
>
>    There MAY be more than one PIDF-LO in the same SIP message, but each
>    in separate message body parts. Each location body part MAY point at
>    different positions on the earth (altitude not withstanding).  If
>    the message length exceeds the maximum message length of a single
>    packet (1300 bytes), TCP MUST to be used for proper message
>    fragmentation and reassembly.
>
>Why is the final sentence stronger than RFC 3261. I assume your thinking 
>is emergency calls, but that is only one of the uses of this document. And 
>surely if emergency calls is the problem, then the requirement has to be 
>made as an update to RFC 3261 for all emergency calls, not just those that 
>happen to carry location.

hmmm... so this is a problem.  I hadn't made that distinction wrt 3261 
language.  If I change this to a SHOULD, will that be acceptable?


>20)     Section 4:
>
>    Several push-based SIP Request Methods are capable (and applicable)
>    of carrying location, including:
>
>       INVITE,
>       REGISTER,
>       UPDATE, and
>       MESSAGE,
>
>    While the authors do not yet see a reason to have location conveyed
>    in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a
>    reason to prevent carrying a PIDF-LO within these Method Requests as
>    long as the SIP message meets the requirements stated within this
>    document.  Discussing Location in the PUBLISH Request Method will be
>    for another document.
>
>The draft seems to go to a great deal of effort to ensure the information 
>is carried end to end, but then suggests that the information might be 
>entrusted to non end-to-end messages.

Maybe I'm missing where a message other than 100 Trying is not 
end2end.  Certainly all requests are intended to be e2e.

>I would suggest that the header and body are declared out of scope for ACK 
>and CANCEL.

I can modify the above to state 'we do not see the point/reason of 
including location in either ACK or CANCEL'.


>21)     Section 4:
>
>    A 200 OK to a SIP Request MAY carry the UAS's PIDF-LO back to the
>    UAC that provided its location in the original request, but this is
>    not something that can be required due to the timing of the request
>    to 200 OK messages, with potential local/user policy requiring the
>    called user to get involved in determining if the caller is someone
>    they wish to give their location to (and at what precision).
>
>I don't understand what this is trying to convey. Please explain?

A 200 OK can carry Location back to the UAC; however, this cannot be an 
expected operation due to the user of the UAS possibly needing to get 
included in whether or not to include their location to the user of the 
UAC.  This delay may be based on who the UAC user is.  This could greatly 
delay call set-up, and delay sending of any response message to the UAC.

Or, the UAS user may have a policy to let certain offerers know the UAS's 
location if they match certain rules within the request (i.e. are on a 
buddy list).

I'm finding this answer to be awkward, but I feel something needs to be 
said here that a UAS may or may not response with location, based on some 
rule match in the request.

suggestions are welcome.


>22)     Section 4.1:
>
>    It is envisioned that HTTP, through the http_URL in [RFC216], and
>    HTTPS [RFC2818] MAY be used to dereference a location-by-reference
>    PIDF-LO.
>
>Do we place any requirement to support HTTP at any location receiver, so 
>that location by reference when received actually works?

JDR got on me about lacking a means to dereference a 
location-by-reference.  Since I don't believe we need another lame usage 
for SIP INFO, I thought we'd suggest that HTTP would be a good fetching 
protocol for a PIDF-LO not locally stored.

What should I do here, change the BNF

         locationURI = absoluteURI / cidURI
to
         locationURI = http_url / https_url / absoluteURI / cidURI
  or
add a requirement in section 3 that receivers of a location by reference 
URI be able to use HTTP/HTTPS to dereference the PIDF-LO?


>23)     Is it not sufficient to say that RFC 2119 applies, and therefore 
>the security considerations of RFC 2119 applies.

I do not understand this comment.  Can you be more verbose?


>NITS
>----
>
>24)     Section 3.1 UAC-8: As by-reference doesn't carry the PIDF-LO 
>within SIP, but within HTTP, the text is wrong.

I think within a by-value message body, it is within SIP.  If I understand 
your point above (about 2 inches), you think this requirement needs to 
change where it states location by-reference within HTTP/HTTPS, correct?


>25)     Can we consistently use "request" or "response" rather than 
>"message" following RFC 3261 terminology?

fair point.  I will change all transactions to requests and responses.


>26)     Section 4:
>
>    Several push-based SIP Request Methods are capable (and applicable)
>    of carrying location, including:
>
>       INVITE,
>       REGISTER,
>       UPDATE, and
>       MESSAGE,
>
>    While the authors do not yet see a reason to have location conveyed
>    in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a
>    reason to prevent carrying a PIDF-LO within these Method Requests as
>    long as the SIP message meets the requirements stated within this
>    document.  Discussing Location in the PUBLISH Request Method will be
>    for another document.
>
>This document is under WG control, the contents have nothing to do with 
>the authors vision!!

OK, and this usage of pov is quite prevelent in documents.  Nonetheless, I 
will change it to omit author's visions.


>27)     Section 4.1: 1st para: delete "and IANA registers"

this comes from an old correction made by an AD (who said to always say 
this if a doc registers anything), but I will remove it

>as superfluous and change "is to be used" to "can be used"

ack


>28)     Suggest using lower case throughout, including initial letter, for 
>the name of the option-tag.

For the option-tag, I thought I had - but I will make sure of 
this.  Location wrt the header needs to be upper case though (correct still?).


>29)     Section 4.1, table of headers needs a table number.

ack

>As it follows the conventions of RFC 3261 (as indicated by reference), it 
>should have an empty space under the "where" column.

my mistake

>However see other technical comments about appearance in responses.
>
>30)     Section 4.2, delete the words "a new 4XX level error is created 
>here", as this is totally obvious from the rest of the words.

ack


>31)     Section 9. Delete "4xx error" before "response code"

ack



>regards
>
>Keith
>
>Keith Drage
>[e-mail]
>tel: [phone]

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